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attaining  a  cost  effective  system  for  access  to  space  is  thereby  enhanced  and  brought  one 
step  closer  to  reality.  Implementation  issues  are  discussed  and  evaluated  along  with 
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I.  INTRODUCTION 


In  America,  "No  natural  boundary  seems  to  be  set  to  the  efforts  of  man;  and  in  his 
eyes  what  is  not  yet  done  is  only  what  he  has  not  yet  attempted  to  do." 

Alexis  de  Tocqueville 

A.  PURPOSE 

This  thesis  was  produced  with  the  objective  of  illustrating  an  innovative  method  for  the 
tracking  of  interface  relationships  and  cost  tradeoffs  in  a  midsized  research  and 
development  program.  The  Sea  Launch  and  Recovery  System  (SEALAR)  was  selected  to 
be  modeled  because  it  is  presendy  in  the  early  stages  of  development  and  is  the  type  of 
p^gram  which  readily  lends  itself  to  be  analyzed  via  a  multimedia  type  database,  in  this 
case,  Machintosh  HyperCard®-  The  overall  objective  is  to  focus  the  reader's  attention  on 
the  merthod  of  presentation  and  the  flexibility  and  potential  of  the  program  employed. 

The  decision  to  use  HyperCard,  a  trademark  of  Apple  Computer  Incorporated,  was 
based  upon  several  factors.  Specifically,  HyperCard's  object-oriented  properties  support 
ease  of  development,  portability  and  reusability  of  modules.  These  characteristics  are 
enhanced  by  the  ability  of  HyperCard  to  link  to  modules  within  itself  or  to  other  programs. 
These  aspects  of  the  program  will  be  discussed  later.  In  addition,  these  same  object- 
oriented  capabilities  provide  the  developer  with  a  rapid,  interactive  prototype  environment 
that  greatly  enhances  debugging  and  ultimately  results  in  a  program  that  has  significantly 
increased  robusmess  over  that  offered  in  other  conventional  programming  environments. 

HyperCard  provides  the  developer  with  a  significant  degree  of  flexibility  and  power, 
and  a  rich  set  of  development  tools  and  options.  When  combined,  these  establish  a  degree 
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of  compatibility  and  cognitive  richness  found  in  few  other  programing  environments.  The 
human  factors  engineering  and  human  interface  technology  found  within  the  Macintosh 
operating  system  have  been  extended  into  HyperCard.  These  features  allow  the  developer 
to  easily  acquire,  manipulate  and  import  text,  sound  and  graphics  into  HyperCard  without 
data  conversion. 

To  demonstrate  the  viability  of  a  multimedia  data  base  employed  in  such  an 
application,  the  SEALAR  X-3  rocket  was  selected.  Due  to  limited  time  and  resources,  this 
initial  implementation  was  aimed  primarily  toward  the  prototype's  propulsion  system. 
However,  it  must  be  noted  that  this  program  is  not  designed  to  demonstrate  applicability  of 
a  specific  function,  rather  its  purpose  is  to  validate  the  integration  possibilities  across  the 
entire  functional  spectrum  of  the  SEALAR  program. 

B. STRUCTURE 

The  thesis  is  organized  into  five  sections.  The  first  section  is  essentially  a  political 
statement  and  assessment  of  where  we  are,  how  we  got  here,  what  avenues  we  are  likely  to 
pursue  as  a  nation  with  regard  to  space  utilization  and  exploration  in  the  future,  and  what 
are  the  primary  motivations  and  drivers  of  this  process. 

The  second  section,  background,  contains  a  brief  history  of  development  of  the  water 
launch  concept,  including  a  summary  of  the  Hydra  and  Sea  Dragon  projects  completed  in 
the  early  60's,  the  ancestors  of  the  SEALAR  coieept 

Within  the  third  section,  programming  enviromnent,  a  brief  overview  is  presented  of 
the  employment  of  HyperCard  and  an  explanation  of  the  object-oriented  programming 
environment.  It  also  includes  a  discussion  of  programming  language  features  and 
ciqiabilities. 
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The  fourth  section,  application,  the  application,  explains  how  the  program  was  built 
and  how  to  manipulate  the  stack  and  its  numerous  features.  Within  it  is  an  explanation  of 
the  programs  required  to  be  installed  on  the  computer  in  order  to  run  the  program  and 
detailed  instructions  of  how  to  operate  it. 

Finally,  the  analysis  and  conclusion  section  gives  an  explanation  of  what  the 
employment  of  HyperCard  programming  could  offer  a  program  like  SEALAR  in  terms  of 
the  ability  to  track  the  interface  relationships  between  components  of  both  off-the-shelf  and 
custom  engineered  components,  and  the  unique  ability  to  quickly  and  objectively  compare 
specification  and  costing  tradeoffs  with  minimal  effort  and  reasonable  reliability. 
Implementation  issues  are  discussed  and  evaluated.  Future  enhancements  to  the  program 
are  also  discussed. 

C.  HISTORICAL  PERSPECTIVE 

Man's  inevitable  quest  for  knowledge  and  adventure  in  the  exploration  and  utilization 
of  space  cannot  be  satisfied  solely  by  the  use  of  machines  and  robots,  as  recently  proposed 
by  some  scientists  and  members  of  Congress.  This  is  not  to  say  that  robots  cannot  play 
important  roles  in  helping  define  and  shape  the  environments  in  which  we  will  travel  and 
live  in  the  future,  and  in  acting  as  sentinels  carefully  placed  along  the  way  in  advance  of 
manned  missions.  However,  in  order  to  make  these  dreams  of  today  a  reality  tomorrow, 
we  require  a  system  offering  reliable  and  cost  effective  access  to  space. 

In  historical  perspective,  machines  have  never  been  used  solely  for  the  exploration  of 
the  earth  and  its  many  environments.  Whether  the  objective  was  the  conquest  of  the  outer 
reaches  of  the  atmosphere  or  the  vast  depths  beneath  the  surface  of  the  world's  oceans, 
machines  might  have  gotten  there  first  but  men  were  never  far  behind.  Machines  lack  the 
innate  ability  to  comprehend  the  unknown,  i.e.,  they  can  only  inform  us  about  physical 
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quantities  that  we  already  are  aware  of.  Of  course  they  can  quantify  and  analyze  these 
known  parameters  more  accurately  and  efficiently  than  a  human.  Therein  lies  both  their 
utility  and  primary  limitation.  The  conquest  of  space  must  be  made  by  manned  vehicles  in 
conjunctitm  with  unmanned  space  probes. 

We  humans  have  made  great  strides  in  our  initial  exploration  of  space:  the  Apollo 
program,  landing  the  first  man  on  the  Lunar  surface  and  returning  him  safely  to  the  earth; 
the  Soyuz  program,  having  a  man  spend  237  continuous  days  in  space;  and  the  Voyager 
program,  a  pair  of  unmanned  space  probes  which  explored  the  outer  planets  of  our  solar 
system,  to  name  only  a  few.  However,  when  compared  to  the  timeline  of  aviation,  which 
in  many  respects,  was  a  similar  development  process,  we  find  that  space  exploration  is 
indeed  still  very  young.  Aviation  had  its  beginnings  with  the  Wright  brothers  first  flight  at 
Kitty  Hawk,  North  Carolina  in  1904.  In  comparison  the  first  terrestrial  instrument  or 
probe.  Sputnik,  was  placed  in  orbit  in  October  1957  by  the  Soviet  Union,  34  years  ago. 
Employing  some  simple  arithmetic  we  find  that  if  we  add  this  figure  to  aviation's  birth  date 
of  1904,  the  result  is  1938.  Qearly,  aviation  was  undergoing  rapid  advances  at  this  point, 
but  was  still  very  young,  with  many  highly  significant  improvements  to  be  made  in  the  next 
S3  years  to  bring  us  to  the  present  Thus  it  can  be  said  with  some  confidence  that  space 
exploration  is  still  in  its  infancy. 

There  is,  however,  one  singular  difference  between  the  development  of  aviation  as  an 
industry  and  space  as  an  industry.  The  development  of  the  aviation  industry,  to  a  great 
extent,  was  performed  by  individuals  and  companies  and  was  financed  substantially  with 
funds  derived  from  the  private  sector.  Even  given  the  increased  military  importance 
attributed  to  aviation  in  the  post  WW I  era,  the  private  sector  was  to  be  the  motivating  force 
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that  was  to  keep  aviation  moving  forward.  The  military,  up  until  the  beginning  of  WW  H, 
had  not  begun  a  credible  and  substantial  development  program  for  the  sole  purpose  of 
developing  military  aircraft. 

The  above  occurred  because  of  several  reasons.  One  was  the  relatively  low  cost  of 
initial  development  of  the  airplane.  The  Wright  brothers  spent  relatively  little  capital  and  a 
substantial  amount  of  time  in  constructing  their  Hrst  aircraft.  Another  was  the  excitement 
and  thrill  of  breaking  records,  of  being  the  fastest  or  having  flown  the  highest  During  the 
20's  and  30's,  individuals  seeking  to  make  substantial  contributions  to  an  infant  industry 
were  eager  and  willing  to  risk  resources,  time  and,  in  some  cases,  even  their  lives.  These 
achievements  were  recognized  by  numerous  awards  and  trophies  on  both  sides  of  the 
Atlantic  and  were  given  with  increasing  regularity  in  the  early  to  mid  20th  century.  Last, 
and  perhaps  the  most  important,  was  the  fact  that  enterprising  individuals  and  companies 
with  foresight  and  vision  recognized  the  potenial  for  realizing  a  profit  from  an  initial 
investment 

In  contrast,  the  development  of  the  space  industry  has  been,  to  a  great  extent,  left  in 
the  hands  of  governments.  The  two  primary  reasons  for  this  include,  one,  the  relatively 
rapid  realization  by  the  military  establishments  of  the  world  of  the  tactical  and  strategic 
applications  of  space  vehicles  and  hardware,  and  two,  the  substantial  cost  required  to 
develop,  build,  and  launch  space  vehicles  and  hence  to  support  a  viable  space  program. 
While  these  reasons  seemed  valid  and  consistent  for  several  decades,  the  paradigm  in  the 
early  90's  now  has  begun  to  change.  The  world  community  has  now  largely 
acknowledged  by  consensus  the  end  of  the  Cold  War  between  the  two  superpowers.  The 
American  public  has  voiced  increasing  demands  upon  the  US  government  to  significantly 
reduce  deficit  spending  and  to  increase  support  and  funding  for  domestic  programs.  In  the 
case  of  the  Soviet  Union,  its  public  demands  the  substantial  reform  of  the  bureaucratic  form 
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of  government,  a  reversal  of  the  trend  of  deterioration  of  their  already  stagnant  economy, 
and  a  move  toward  an  open  market  system  interacting  freely  with  Europe  and  the  West. 

As  a  direct  result  of  the  above  factors,  the  oend  is  toward  a  reduction  of  the 
governmental  control  and  subsidization  of  the  space  industry  within  the  United  States  and 
the  Soviet  Union.  This  ultimately  means  that  once  again  the  private  sector  must  be 
encouraged  to  bear  the  burden  and  take  the  required  risks  if  we  are  to  continue  to  explore 
and  develop  our  understanding  of  space.  However,  because  of  the  tremendous  cost 
involved,  this  cannot  happen  of  its  own  accord.  The  governments,  endorsed  by  bold  and 
strong  political  leaders  of  the  world,  must  support  and  nurture  this  fledgling  industry,  at 
least  until  it  gains  sufficient  momentum  and  becomes  a  going  enterprise,  i.e.,  until  it 
becomes  profitable.  In  retrospect,  had  H.  G.  Wells  fictional  Baltimore  Gun  Club  been  a 
reality,  and  if  its  visionary  members  possessed  the  enormous  capital  required  to  develop 
aikl  test  a  space  vehicle,  the  world  could  have  been  vastly  different  today. 

As  the  decade  of  the  nineties  begins  and  we  look  toward  the  21st  century  several 
important  trends  become  evident.  One,  economies  around  the  world  are  being  restructured, 
primarily  as  a  result  of  failed  ideologies  and  of  excessive  deficit  spending,  both  factors 
ultimately  resulting  in  recession  and  economic  stagnation.  These  realities  will  presumably 
lead  to  an  altered  global  power  structure  based  upon  economics  rather  than  strictly  military 
prowess  and  might  World  leaders  will  increasingly  be  compelled  to  recognize  that  in 
conjunction  with  this  power  comes  the  burden  of  accountability.  While  U.S.  leaders  have 
to  some  degree  had  to  deal  with  this  factor  in  recent  years,  other  world  leaders  will  find  this 
a  new  and  often  annoying  challenge.  As  a  direct  result  of  technological  advances  in  the 
field  of  communications  and  travel  in  the  last  twenty  years,  news  events  and  advertising 
have  developed  an  informed  and  educated  public  and  constituency.  World  leaders  will  be 
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increasingly  held  accountable  for  their  actions  and  decisions,  many  of  which  may  well  have 
long  term  effects  upon  our  global  environment,  as  well  as  short  term  impacts  upon  regional 
economies. 

Another  important  trend  of  the  90's  will  involve  space.  Its  exploration,  exploitation, 
and  conquest  will  ultimately  become  dominant  factors  in  defining  our  future  and  will  hold 
the  keys  to  our  destiny.  The  realities  of  this  statement  wiU  become  increasingly  evident  as 
the  decade  unfolds.  The  earth  provides  only  limited  and  inequitably  distributed  resources 
upon  and  beneath  its  surface.  Scientists  and  environmentalists  now  acknowledge  the 
perceptible  and  increasingly  evident  deterioration  in  the  quality  of  our  air  and  water.  This 
sequence  of  disturbing  events  is  occurring  primarily  as  a  result  of  the  increasingly  rapid 
exploitation  and  utilization  of  these  finite  resources.  In  the  not  so  distant  future,  the  use  of 
extraterrestrial  sources  of  power  and  raw  materials  may  be  not  only  economically  prudent 
and  advantageous,  but  the  ultimate  survival  of  the  human  species  might  well  come  to 
depend  upon  it. 

The  rules  and  paradigms  have  changed  with  regard  to  advancing  technology  and  space 
exploration.  Where  deficit  spending  was  the  norm  in  the  late  70's  and  80's,  and  where 
excessive  funding  was  ultimately  available  when  required  and  not  an  insurmountable 
problem,  the  systems  designed  and  built  to  date  largely  reflect  this  fundamentally  flawed 
policy.  Now,  largely  because  of  economic  necessity  and  the  lack  of  strong  public  support, 
we  are  compelled  to  rethink  and  redesign  our  programs,  systems  and  hardware  and  attempt 
to  achieve  previously  established  goals  within  this  now  constrained  economic  environment. 

As  we  plan,  develop  and  prepare  to  launch  our  third  generation  earth  sensing  platforms 
and  space  probes,  it  is  very  likely  that  they  will  be  significantly  different  firom  their 
predecessors  in  several  aspects:  they  will  be  the  result  of  significantly  more  international 
cooperation  and  funding;  they  will  reflect  the  economic  conditions  and  realities  within 
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which  they  were  conceived;  they  will  likely  be  smaller  and  lighter,  and  inasmuch  as 
possible  be  multifunctional  in  their  capabilities.  Additionally,  they  will  be  placed  into  space 
by  a  new  generation  of  cost  effective  launch  vehicles. 

With  the  question  of  cost  ultimately  driving  the  whole  issue  of  how  and  with  what 
vigor  a  space  program  is  to  be  pursued,  it  becomes  evident  that  the  major  factors  that  drive 
cost  must  be  fully  understood  and  optimized.  This  question  is  not  new.  During  the  last  of 
the  Apollo  missions  in  the  early  1970's,  forward  looking  individuals  and  planners  had 
recognized  that  fiscal  constraints  would  increasingly  affect  the  U.S.  space  program.  In  the 
following  excerpt  from  a  Navy  Space  Systems  Activity  report,  the  answer  to  the  cost 
dilemma  was  as  follows: 


The  existing  launch  systems  are  very  expensive  to  operate  because  their  hardware  is 
completely  expended  during  each  single  mission  -  the  present  cost  per  pound  of  payload 
delivered  to  low  Earth  orbit  is  on  the  order  of  $800  to  $1000  (FY  73).  Economic 
considerations  demand,  and  the  experience  gained  during  the  first  ^teen  years  of  space 
flight  makes  it  possible,  to  develop  a  reusable  Space  Transportation  System  for  a 
vigorous  continuation  of  space  exploration  during  the  next  decade  and  beyoi^ 

The  development  of  the  reusable  Space  Transportation  System  signals  the  end  of 
the  initial  "brute  force"  period.  Space  flight  operations  will  l^ome  to  a  large  degr^ 
routine,  like  those  of  intercontinental  airlines.  Payload  delivep^  costs  to  low  Earth  orbit 
will  be  reduced  by  the  Space  Shuttle  to  about  $150  per  pound  iiutiaUy,  and  later  to  about 
$100  per  pound.  The  tremendous  impact  of  the  new  Space  Transportation  System  on 
Ground  (^rations  including  Range  Stdety,  Communication,  Reentry,  Recovery  and 
Retrieval  will  also  be  signiflcantly  i^uced.iRef.  1] 

While  the  motivation  and  intent  of  the  Space  Shuttle  concept  was  undisputably  in  the 
right  direction,  several  elements  ultimately  leading  to  the  failure  to  reach  its  cost  objectives 
should  be  discussed.  The  Space  Shuttle  from  its  conception  was  to  be  a  man-rated  system. 
This  factor  in  and  of  itself  required  extraordinarily  high  reliability,  one  of  the  primary  cost 
drivers  of  such  a  space  system.  Secondly,  the  employment  of  numerous  leading  edge 
technologies  throughout  the  system,  some  of  which  were  not  even  through  the  research  and 
development  stage  at  its  conception,  contributed  great  uncertainty  and  unforeseen 
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technological  challenges,  ultimately  leading  to  a  significantly  higher  than  estimated  final 
system  cost.  Lastly,  the  cost  of  direct  support,  turnaround  and  refurbishment,  and 
bureaucratic  support  were  not  accurately  estimated  nor  maintained  within  reasonable 
bounds.  "The  Space  Shuttle  system  has  ended  up  being  extremely  expensive  to  maintain 
and  launch.  "[Ref.  2] 

By  the  mid  1980s,  when  the  bills  began  to  arrive  in  Congress,  inquiring  minds  wanted 
to  know  if  there  was  a  better,  more  cost  efficient  system.  Specifically,  the  House 
Committee  on  Science,  Space,  and  Technology,  and  the  Senate  Committee  on  Commerce, 
Science,  and  Transportation  requested  and  funded  an  assessment  of  available  space 
transportation  technologies.  The  broad  realization  was  clearly  that: 

. . .  low-cost  transportation  is  one  of  the  keys  to  more  efficient  exploration  and 
exploitation  of  outer  space.  If  space  transportation  costs  were  much  lower, 
government  agencies  and  private  firms  with  good  ideas  for  using  the  space 
environment  might  be  more  >^ling  to  risk  their  investment  capital.[Ref.  3] 

One  plausible  option  was  a  concept  which  had  been  around  for  many  years,  and  was 
in  fact  originally  proposed  by  German  missile  engineers  at  Peenemiinde,  toward  the 
conclusion  of  World  War  n.  They  proposed  enclosing  a  V-2  rocket  in  a  large  cannister  and 
launching  it  out  of  the  water  in  a  vertical  position.  Following  the  war,  the  U.S.  Naval 
Missile  Center  at  Point  Mugu,  California  continued  research  in  this  area  under  the  name 
"Project  Hydra".  The  stated  policy  of  such  research  was  "to  develop  vertical  floating 
launch  technology,  and  to  apply  it  to  both  long-range  missiles  and  satellite  boosters".  When 
the  project  was  canceled  in  1965,  "it  was  generally  conceded  that  the  feasibility  of  this  type 
of  launch  has  been  proven".[Ref.  4] 

Ultimately,  in  order  to  realistically  fulfill  mankind's  needs  and  desires,  a  reliable 
cost  effective  system  is  required  for  placing  materials  and  supplies  into  space.  Only 
then  will  man  be  able  to  continue  to  explore  the  universe  and  to  discover  what  is  on  the 
next  planet  ot  beyond  the  next  star. 
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II.  CONCEPT  AND  DEVELOPMENTAL  HISTORY 


The  decade  of  the  60's  was  perhaps  the  most  exciting  for  space  exploration  and 
development  to  date.  The  decade  began  with  the  American  and  Russian  space  programs 
attempting  to  outclass  one  another  in  the  "space  race.”  With  the  lead  position  in  serious 
doubt,  the  recently  elected  Democratic  President,  John  F.  Kennedy,  "instructed  his  Vice 
President,  Lyndon  B.  Johnson,  to  work  with  National  Aeronautics  and  Space 
Administration  (NASA)  and  seek  out  ways  by  which  the  United  States  could  overtake  the 
Soviet  Union  and  demonstrate  a  superior  American  technology  in  full  view  of  every  nation 
on  Earth.  The  ambitious  goal  would  need  dedication  to  objectives  which  would 
demonstrate  a  clear  cut  lead  for  the  United  States.  It  was  decided  that  only  a  manned 
landing  on  the  surface  of  the  Moon  was  sufficiently  in  advance  of  contemporary  Soviet 
accomplishments  to  give  the  space  agency  a  fighting  chance  of  getting  there  before  the 
Russians. "[Ref.  51 

Consequently,  on  25  May  1961,  President  Kennedy  went  before  Congress  and  called 
for  a  massive  new  commitment  to  space  exploration:  "Now  is  the  time  to  take  longer 
strides  -  time  for  a  great  new  American  enterprise  -  time  for  this  nation  to  take  a  clearly 
leading  role  in  space  achievement,  which  in  many  ways  may  hold  the  key  to  our  future 
Earth.  I  believe  that  this  nation  should  commit  itself  to  achieving  the  goal,  before  this 
decade  is  out,  of  landing  a  man  on  the  Moon  and  returning  him  safely  to  the  Earth.  No 
single  space  project  in  this  period  will  be  more  impressive  to  mankind,  or  more  important 
for  the  long  range  exploration  of  space;  and  none  will  be  so  difficult  or  expensive  to 
accomplish."[Ref.  5] 
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During  this  period 

NASA  was  rife  with  optimism.  The  Apollo  program  had  been  authorized,  and  the 
entire  country  was  excited  about  space.  It  was  felt  that  a  manned  space  station,  a 
manned  lunar  base,  or  a  manned  mission  to  Mars  would  follow  hard  on  the  heels  of 
Apollo.  It  was  recognized,  however,  that  not  all  of  these  missions,  perhaps  none  of 
them,  could  be  achieved  unless  the  cost  of  transportation  from  earth  to  low  orbit  could 
be  drastically  reduced.  "[Ref.  6] 

It  was  during  this  decade  that  two  unique  concepts  were  to  be  partially  developed,  which 
some  35  years  later  would  provide  the  basis  and  conceptual  foundations  for  the  SEALAR 
program. 

During  the  early  60's  a  U.S.  Navy  research  team  at  the  Naval  Missile  Center,  Point 
Mugu,  California,  proposed  development  of  techniques  for  launching  large  solid-propellant 
rockets  from  the  ocean.  The  project,  headed  by  Lieutenant  Commanders  John  E.  Draim 
and  Charles  E.  Stalzer,  came  to  be  known  as  "Project  Hydra."  The  initial  concept  was  to 
attack  directly  the  deficiencies  of  land-based  launch  and  support  facilities.  Throughout  the 
life  of  the  project,  "approximately  sixty  successful  launches  of  rocket  simulators  and  actual 
rockets  confirmed  the  feasibility  of  the  basic  launch  method-floating  the  rocket  vertically 
and  exhausting  gases  directly  into  the  water.  Shapes  ranging  from  3  feet  to  105  feet  in 
length,  and  weights  of  20  pounds  to  more  than  10  tons,  have  been  successfully  launched  in 
this  manner."[Ref.  7]  Most  were  constructed  from  surplus  Department  of  Defense  and 
NASA  assets,  requiring  little  modification  and  costing  little  or  nothing  to  acquire.  While 
most  tests  employed  solid-propellant  rockets,  several  storable  liquid  rockets  were  also 
launched  successfully. 

The  floating-launch  concept  was  deceptively  simple.  Bare,  unencapsulated  rockets 
were  waterproofed  and  made  buoyant  (through  design  or  the  addition  of  external 
floats).  As  the  rocket  motor  built  up  to  full  thrust,  the  floating  rocket  rose  vertically 
from  its  wet  pad.  Once  clear  of  the  water,  it  was  indistinguishable  from  any  land- 
launched  rocket.  Surprisingly,  tests  showed  that  the  added  upward  force  of  buayanqr 
actually  resulted  in  a  performance  benefit  over  land-launched  missiles.[Ref.  8] 


Several  important  military  advantages  became  readily  apparent  as  the  project 
progressed.  The  team  found  that  any  type  of  platform  (i.e.,  ship,  barge,  submarine,  etc.) 
was  easily  made  capable  of  transporting  and  launching  a  rocket  employing  the  Hydra,  or 
vertical  floating  launch  technique.  Very  large  missiles  could  be  handled  with  little  more 
difficulty  than  was  experienced  with  smaller  ones.  Finally,  it  was  realized  that  an  awesome 
concentration  of  Hrepower  was  possible,  since  any  number  of  missiles  could  be  launched 
simultaneously. 

As  the  Hydra  Project  progressed,  the  research  team  at  Point  Mugu  proposed  an 
ambitious  and  extensive  development  plan.  Since  it  was  determined  that  operational  and 
technical  problems  would  depend  upon  the  specific  size  and  mission  of  the  vehicle 
produced,  the  team  grouped  the  proposed  vehicles  into  four  classes.  Figure  1  is  reproduced 
from  the  "Hydra  Program  Plan"[Ref.  9]  and  depicts  the  class  distinctions  envisioned.  It 
also  illustrates  the  progress  completed  in  reaching  the  denoted  milestones. 
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NAVY-WIDE  HYDRA  PROGRAM 
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SPACE  VEHICLE  AERO.  STABILITY 


Within  this  figure  is  depicted  a  systematic  approach  to  the  development  of  a  unique 
class  of  launch  vehicles.  Initially  the  prototype  test  vehicles,  consisted  largely  of  surplus 
and  custom  one  of  a  kind  rockets  and  missiles.  The  development  of  unguided  suborbital 
probes  followed,  employing  and  refining  the  design  features  and  elements  derived  from  the 
previous  test  vehicles.  They  continued  in  complexity  and  development  to  the  third  class  of 
suborbital  guided  probes  and  weapons.  This  process  culminated  into  a  class  of  orbital 
space  vehicles,  employing  all  of  the  features  of  the  previous  developmental  stages  and  the 
same  technology  and  construction  principles. 

Despite  a  very  long  string  of  successful  launches  and  an  ambitious  program  plan,  the 
Navy  canceled  the  Hydra  program  in  1965.  While  documentation  explaining  the  decision 
is  not  available,  one  can  only  assume  that  with  the  Viemam  conflict  looming  on  the 
horizon,  the  Navy  had  more  important  commitments  elsewhere. 

Also  during  this  period,  a  retired  Naval  officer,  Robert  C.  Truax,  working  as  Director 
of  Advanced  Developments  at  the  Aerojet-General  Corporation,  initiated  an  effort  to 
discover  the  root  causes  of  the  high  cost  of  space  transportation  and  to  formulate  some 
principles  for  achieving  more  cost-effective  designs.  After  collecting  and  examining  all  of 
the  available  data,  his  team  reached  the  following  conclusions; 

Costs  vary  only  slowly  with  size,  but  very  sharply  with  complexity,  reliability, 
design  margins,  and  "programmed  invention."  A  large  fraction  of  the  cost  of  a  space 
launch  resided  in  the  propulsion  hardware  that  was  tlrown  away.  A  low-cost  launch 
vehicle,  therefore,  should  be  big,  simple,  reusable,  not  too  reliable,  and  use  existing 
state  of  the  art  technology  wherever  possible.[Ref  10] 

The  Aerojet  team  went  on  to  design  a  vehicle,  which  in  their  estimation,  would  be 
capable  of  fulfilling  all  foreseen  mission  requirements.  Using  accumulated  data  supplied 
from  Marshall  Space  Flight  Center  (MSFC)  and  NASA,  they  devised  a  cost-optimized 
design  based  upon  the  principles  previously  described,  making  trade-offs  largely 
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intuitively,  and  in  general,  tending  away  from  existing  configurations.  This  resulting 
design  was  dubbed  "Sea  Dragon."[Ref.  11]  The  economy  of  the  "Sea  Dragon"  was 
obtained  not  through  ever-increasing  sophistication  but  through  its  great  size,  simplicity 
and  reusability.  [Ref  10]  This  prototype  design  embodied  the  characteristics  deemed 
necessary  for  a  low-cost  launch  vehicle: 

-  It  was  big,  500  feet  tall  and  75  feet  in  diameter,  and  had  a  liftoff  weight  of  40  million 
pounds;  it  was  capable  of  lifting  to  low  earth  orbit  (LEO)  nearly  1.1  million  pounds 
of  payload  per  flight. 

-  It  was  simple;  only  two  pressure-fed  stages  were  used  to  attain  LEO  (300  nm). 
Each  stage  had  only  one  main  propulsion  engine.  Propellants  used  in  the  first  stage 
were  kerosene  and  liquid  oxygen,  in  the  second,  liquid  hydrogen  and  liquid  oxygen. 

-  It  was  reusable;  the  simplest  and  lightest  means  available  to  return  the  stages  to  earth 
were  used:  a  parachute-like  drag  device  on  the  first  stage,  and  a  heat  shield  plus  drag 
device  on  the  second. 

-  It  was  sea  launched;  it  was  built  in  a  drydock,  towed  to  a  lagoon,  checked  out 
dockside,  fueled  at  sea,  erected  by  flooding  ballast,  and  launched  directly  out  of  the 
water.  [Ref.  11] 

The  report  was  submitted  to  NASA  for  review  and  scrudnization.  Eventually,  being 
skeptical  because  of  its  significantly  lower  predicted  cost  per  pound  to  low  earth  orbit, 
NASA  let  a  contract  to  Space  Technology  Laboratory  (now  TRW)  to  reevaluate  and 
presumably  discredit  the  Aerojet  team's  costing  analysis.  Surprisingly  however,  the  results 
of  this  costing  review  largely  supported  the  original  study's  estimations. 

Unfortunately,  NASA  funding  began  to  decline  after  fiscal  year  1964  and  by  the  end 
of  the  decade  was  down  from  its  peak  of  $  5,350.8  million  to  $  3,786  million  in  fiscal  year 
1970.  This  factor,  combined  with  the  public's  apparent  disinterest  in  repeated  Moon 
landings  by  the  early  70's  and  the  increase  in  spending  required  to  fight  the  war  in 
Viemam,  led  to  the  termination  of  funding  for  new  vehicle  concepts  by  NASA.  As  a  result 
the  "Sea  Dragon"  studies  were  never  pursued  and  explored. 
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Looking  back,  one  can  only  wonder  what  systems  might  be  in  place  today  had  these 
two  apparently  promising  concepts  been  allowed  to  be  developed  fully. 

By  the  early  80's.  numerous  exercises,  operational  studies,  and  wargames  had 
identified  the  requirements  to  proliferate  and/or  reconstitute  space-based  assets  in  times  of 
crisis  and  in  war.  Most  recendy  this  need  was  demonstrated  and  validated  in  the  E)esert 
Shield  and  Desert  Storm  operations  in  the  Middle  East.  This  capability  shortfall  has  led  the 
Department  of  Defense  to  search  for  a  low  cost-per-pound  to  low  earth  orbit  (LEO)  space 
transportation  system  offering  increased  operational  flexibility,  redundancy,  and 
responsiveness.  Further,  application  of  the  concept  could  be  realized  within  the 
commercial  sector  as  a  cost-competitive  launch  vehicle  for  industrial  applications. 

The  motivation  to  pursue  the  sea  launch  and  recovery  concept  is  not  new,  as 
previously  alluded  to.  Additionally,  the  requirements  suppoting  the  development  of  such  a 
concept  are  not  singular  in  nature.  It  is  of  fundamental  importance  to  understand  both  the 
motivation  and  requirements  for  a  sea  launch  and  recovery  type  vehicle.  Only  then,  can 
one  fully  appreciate  the  importance  and  significance  of  developing  SEALAR  as  a  viable 
alternative  and  supplement  to  the  assets  presently  available  for  placing  both  men  and 
equipment  into  space. 

In  1986,  DOD  5100.1  "Function  of  the  Department  of  Defense  and  Its  Major 
CompcMients"  described  two  functions  of  the  Department  of  the  Navy  (DON): 

1)  Develop  in  coordination  with  the  other  services,  procedures  and  equipment 
employed  by  the  Navy  and  Maritre  Corps  fences  in  the  conduct  of  space  ope^ons 

2)  Provide  sea-based  launch  and  space  support  for  the  Department  of  Defense  when 
directed 

The  Secretary  of  the  Navy  opened  discussion  within  the  Navy  in  1987  asking  such 
questions  as:  "Will  the  technology  work?"  "Is  the  SEALAR  concept  advantageous  to  the 
Navy?"  "How  promising  is  the  development  of  a  sea-based  launch  platform?" 
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Consequently,  the  SEALAR  program  was  initiated  after  gaining  support  from  the  Chief  of 
Naval  Research,  Commander  Naval  Space  Command,  and  Director  of  the  Naval  Center  for 
Space  Technology  (NCST).  NCST  of  the  Naval  Research  Laboratory  (NRL)  has  become 
tl»  primary  source  for  personnel  and  resources  for  the  project. 

On  the  private  sector  side  of  the  equation,  Truax  Engineering  Inc.  (TEI)  submitted  a 
proposal  in  response  to  the  original  NCST  Broad  Area  Aimouncement  which  appeared  in 
Commerce  Business  Daily  on  25  August  1988.  The  proposal  submitted  included  both 
analytical  and  experimental  woiic  which  had  been  completed  to  date  exclusively  with  private 
funds  in  support  of  the  company's  goal  of  ultimately  demonstrating  the  principles  set  forth 
in  the  original  "Sea  Dragon"  proposal  some  35  years  ago. 

The  Navy  purchased  the  Truax  Engineering  prototype  rocket,  called  the  X-3, 
along  with  all  associated  ground  support  equipment  for  the  fixed  price  of  $750,000. 
Along  with  the  rocket  the  Navy  gain^  any  patent  rights  or  othCT  intangibles  associated 
with  it  and  owned  by  Truax  Engineering  Inc.,  including  the  right  to  have  the 
equipment  or  any  portion  of  it  reproduced  by  others  without  further 
compensation.[Ref.  12] 

The  present  SEALAR  project  is  envisioned  as  the  integration  of  the  various  design 
concepts  which  will  ultimately  lead  to  the  development  of  a  new  family  of  simple,  mobile 
and  reusable  space  launch  vehicles.  These  SEALAR  launch  vehicles  portend  to  provide 
low  cost  and  reliable  access  to  space  through  the  use  of  the  following  fundamental  design 
concepts: 

-  Low  cost  liquid  propellants  (LOX,  Kerosene,  LH2) 

Provides;  Low  cost,  ease  of  handling 

-  Two  stages  to  Low  Earth  Orbit  (LEO)  design 

Provides:  Simplicity,  reliability  and  low  cost 

-  Single  engine  per  stage 

Provides:  Simplicity,  reliability  and  low  cost 

-  Pressure  fed  engine  desi^ 

Provides:  Simplicity,  reliability  and  low  cost 
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•  Low  chamber  pressure  engines 

Provides:  Simplicity,  reliability  and  low  cost 

-  Hydrogen  dump  cooling  of  large,  low  pressure  thrust  chambers 
Provides:  Low  weight  penalty  allowing  larger  payloads 

-  Low  cost  high  strength  tanks,  constructed  employing  conventional  technology 
Provides:  Simplicity,  reliability,  performance,  and  low  cost 

-  Global  Positioning  System  (GPS)  navigation 

Provides:  Simplified  logistics,  reliability  and  low  cost  [Ref  13] 

Recently,  Truax  Engineering  Inc.,  under  the  direction  of  the  Naval  Center  for  Space 
Technology  and  in  conjunction  with  the  Naval  Research  Laboratory  have  set  up  a 
comprehensive  test  plan.  Initially,  employing  the  X-3  rocket  as  the  primary  test  vehicle, 
the  test  plan  objectives  include  the  verification  of  the  design  features  of  a  water-launched 
vehicle,  and  multiple  use  and  refurbishment  characteristics.  Also,  through  repeated 
launches  and  recoveries,  experience  can  be  provided  from  which  more  accurate  estimates  of 
turnaround  costs  may  be  made. 

Lastly,  and  perhaps  most  importantly,  the  following  two  tables  (Tables  1  and  2) 
vividly  illustrate  the  advantages  and  benefits  of  the  SEALAR  concept  over  that  of 
conventional  expendable  launch  vehicles. 
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COMPARISON  OF  SEALAR  AND 
EXPENDABLE  LAUNCH  VEHICLE  (ELV) 
CONCEPTS 

FACTORS  UNIQUE  TO  SEA  LAUNCH 


TABLE  1 


SEALAE 

Conventional 

Parameter 

Canceia 

ELVs 

Launch  Inclination 

Water  Launch  allows 
feasibility  to  matt:h  launch 
latitude  to  orbit  inclination 
for  optimization  of  payload 
performance 

Fixed  US  launch  site 
locaticms,  at  roughly  40N 
latitude,  result  in  payload 
performance  reductitxi  for 
low-inclinati(m  orbits 

Launch  Rate 

The  Water  Launch  Concept 
allows  for  an  unconstrained 
launch  rate 

Launch  rate  limited  by  pad 
availability  (typically  4 
launchesA'car/p^)  -  could 
preclude  high  launch  rate 
programs 

Launch  Azimuth 

Unconstrained  with  Water 
Launch  afftmling  maximum 
missicm  performance 

Limited  by  ground 
overflight  restrictions  - 
required  ^g  leg  maneuvers 
redwx  achievable 
performance  and  add 
complexity 

Launch  Pad  Refurbishment 

Water  Launch  results  in 
minimal  damage  to  launch 
support  inf^tructure, 
thereby  reducing  cost 

Extensive  pad  refurbishment 
required  after  each  launch 
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COMPARISON  OF  SEALAR  AND 
EXPENDABLE  LAUNCH  VEHICLE  (ELV) 
CONCEPTS 

FACTORS  NOT  UNIQUE  TO  SEA  LAUNCH 

TABLE  2 


Paramgtgr 

2EALAE 

Coocspi 

ConventiQnal 

ELV«: 

Launch  Reliability 

Ultra  Conservative  Design 
provides  high  ccmfidence 
launch;  may  sacrifice  some 
performance  for  reliability 

Emphasis  on  high 
performance  with  inherently 
complex,  pump-fed  engines 

Launch  Vehicle  Cost 

Conservative  approach  of 
simplicity  over  optimized 
performance  minimizes  cost 

Stress  on  high  performance 
over  simpUci^  results  in 
high  cost 

Launch  Vehicle  Stage  Reuse 

Attractive  cost  savings 
possible  through  recoverable 
and  reusable  staging  concept 

Expendable  Launch  Vehicle 
emreepts,  by  definition 
preclude  reuse,  a  potential 
cost  savings 

Launch  Support 
Infrastructure 

Building-block  launch 
vehicle  approach  provides 
for  common  mission 
support  facility 

Unique  launch  pads  for  each 
ELV  type  results  in 
inefficient  pad  utilization  and 
non  standard  logistic 
requirements 
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It  appears  that  the  development  of  the  SEALAR  technology  will  provide  the  U.S. 
Navy,  as  well  as  other  government  and  commercial  interests,  a  low-cost-per-pound  space 
transportation  system  with  increased  responsiveness,  survivability,  capacity,  flexibility, 
and  operation  availability.  With  such  a  space  transportation  system  a  reality,  it  will  become 
possible  to  satisfy  all  of  the  present  major  space  missions  in  an  economic  fashion, 
including  Space  Defense  Initiative  (SDI),  the  manned  space  station  (Freedom),  a  manned 
Lunar  base,  and  the  Manned  Mission  to  Mars. 
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m.  THE  PROGRAMMING  ENVIRONMENT;  HYPERCARD™ 


In  this  section  the  primary  programming  development  tool,  HypeiCard/HyperTalk™, 
will  be  briefly  described.  The  programming  environment  HyperCard  was  developed  by 
Apple  Computer®  Incorporated.  It  is  designed  to  run  exclusively  on  the  Macintosh™ 
family  of  computer  hardware.  It  is  now  being  marketed  as  an  extension  of  the  Macintosh 
operating  system.  The  HyperCard,  Version  2.0  edition,  was  used  for  the  development  of 
the  program  on  which  this  thesis  was  based. 

HyperCard  is  an  event-driven,  object-oiented  programming  environment  that  is  driven 
by  messages  to  and  from  objects.  Actions  are  initiated  in  response  to  events  which  then 
send  a  chain  reaction  of  messages  from  one  object  to  another.  HyperCard,  also  contains  a 
general  purpose  programming  language  called  HyperTalk.  This  programming  language 
provides  tools  for  painting,  editing  functions  and  semiautomatic  program  development. 
HyperCard  is  truly  a  multi-media  development  system  that  affords  the  programmer  the 
ability  to  rapidly  and  easily  integrate  graphics,  text  and  audio  into  an  object-oriented 
environment. 

The  programmer  interface  with  HyperCard  is  very  intuitive  and  easily  learned;  this  is 
true  as  well  for  the  user.  An  individual  with  little  or  no  programming  background  is  able  to 
create  very  professional  looking  programs  without  writing  any  code.  At  the  other  end  of 
the  spectrum,  a  experienced  programmer  is  capable  of  creating  powerful  functions  and 
commands  written  in  other  computer  languages,  which  may  not  be  presently  available  in 
the  HyperTalk  functions.  HyperCard  has  proven  to  be  a  substantial  labor  saving 
developmental  environment  and  has  significantly  extended  the  domain  of  software 
development 
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HyperCard  uses  the  metaphor  of  a  stack  as  an  object  that  can  hold  both  processes  and 
data,  and  exists  only  in  the  context  of  a  stack.  It  is  important  to  point  out  that  a  HyperCard 
stack  is  uniquely  different  from  the  classical  data  structure,  in  that  it  can  be  accessed  from 
top  or  bottom  or  anywhere  in  between.  HyperCard  supports  development  of  stacks  that 
allow  data,  which  may  be  any  combination  of  text,  graphics  and  sound,  to  be  stored, 
linked,  searched  and  or  viewed.  This  unique  set  of  attributes  provides  for  the  basis  of  the 
multi-media  database  application.  Information  may  readily  be  linked  relationally  within  a 
stack  or  from  one  stack  to  another.  HyperCard  is  clearly  not  a  replacement  for  traditional 
databases.  However,  as  a  stand  alone  multi-media  database  development  tool,  HyperCard 
allows  applications  to  be  constructed  in  minutes  that  would  require  monumental  effort  in 
conventional  programming  language. 

Within  the  HyperCard  programming  environment  there  exist  five  pre-defined  objects. 
They  are  buttons,  fields,  backgrounds,  cards  and  stacks.  All  HyperCard  objects  are  able  to 
send  and  receive  messages;  have  unique  properties  including  script  which  is  code 
associated  with  that  particular  object;  and  have  a  visible  representation  that  may  be  turned 
on  or  off.  A  button  is  a  specified  area  on  a  card  that  is  accessible  with  the  mouse  pointer. 
Buttons  may  be  graphical,  textual,  a  combination  of  both  or  totally  invisible.  When  the 
user  clicks  the  mouse  pointer  on  a  button,  a  message  will  be  sent  to  the  button  and  the 
script  of  the  button  will  be  executed.  A  field  is  an  area  in  which  textual  data  is  stored  on  a 
given  card.  Fields  are  not  static.  They  may  be  adjusted  to  any  desired  size,  shape  or 
appearance.  Field  scripts,  like  all  scripts  in  HyperCard,  are  also  event  driven. 
Backgrounds  are  objects  that  cards  often  times  share  to  give  the  program  a  homogeneous 
look.  Cards  are  the  objects  on  which  fields,  buttons  and  backgrounds  reside.  A  stack  can 
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consist  of  only  a  few  cards  or  several  million  depending  upon  the  application.  The  stack, 
along  with  the  objects  it  contains,  cards,  backgrounds,  buttons  and  fields,  and  any  attached 
outside  resources,  constitute  the  executable  program. 

Modularity  is  a  unique  property  of  objects  in  HyperCard.  Once  created  an  object  may 
be  moved  in  its  entirety  to  another  stack  with  its  graphical  appearance,  scripts  and  resources 
intact.  This  feature  makes  HyperCard  particularly  suitable  for  rapid  prototype  development 
and  facilitates  code  reusability. 

Sending  messages  is  an  important  characteristic  of  an  object-oriented  programming 
environment.  HyperCard  generates  messages,  called  system  messages,  which  are  sent  to 
objects  in  response  to  certain  program  events.  This  affords  the  programmer  the  ability  to 
model  real  world  data  efficiently  and  accurately.  It  also  permits  the  establishment  of 
browse,  search  and  reporting  capabilities  within  a  program. 

Whenever  script  is  executed  a  message  is  generated.  The  first  object  to  receive  the 
message  is  the  sendutg  object  and  if  it  has  a  message  handler  (a  subroutine  in  HypeiTalk)  it 
will  execute  the  handler.  The  script  can  also  call  the  same  message  handler  frtmi  which  the 
message  originated.  This  is  called  recursion  in  HyperTalk.  HyperTalk  is  also  capable  of 
nesting,  which  would  occur  if  handler  1  in  object  A  calls  handler  2  also  residing  in  object 
A.  These  capabilities  allow  the  developer  to  create  data  structures  similar  to  those  found  in 
conventional  programming  languages. 

Within  HyperCard  are  found  two  types  of  objects:  transparent  and  opaque. 
Transparent  objects  are  virtually  invisible,  that  is  they  allow  the  user  to  look  down  through 
layers  of  cards  below  the  top  layer.  Opaque  objects  however  are  solid.  Consequently, 
they  block  the  user  from  observing  objects  directly  below.  Every  HyperCard  object  is 
created  in  its  own  layer,  the  layers  are  placed  one  on  top  of  the  other  as  the  objects  get 
added  to  the  stack.  The  layers  perhaps  can  be  best  visualized  as  infinitely  thin  sheets  of 
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clear  plastic.  Opaque  objects  are  visible  through  all  layers  of  the  stack  regardless  of  their 
relative  stack  position,  that  is  unless  they  get  covered  by  another  opaque  object  in  a 
subsequent  layer  which  would  render  the  lower  object  impossible  to  be  seen  by  anyone 
looking  down.  Transparent  objects  allow  the  user  to  observe  q)aque  objects  below. 

Buttons,  which  are  a  type  of  HyperCard  object,  can  be  layered  into  a  stack  like  any 
other  object.  Whether  transparent  or  opaque,  buttons  will  react  to  pointer  mouse  clicks 
regardless  of  depth  in  the  layer.  This  is  different  from  transparency,  in  that,  when  an 
object's  visibility  is  set  to  false  the  object  not  only  cannot  be  seen  but  is  also  deactivated. 
However,  attributes  of  an  object  whose  visibility  is  set  to  false  may  be  obtained  or  changed 
through  the  use  of  the  scripting  language  HyperTalk.  Visibility  and  layering  together 
provide  the  programmer  with  the  ability  to  construct  complex  data  structures  and  establish 
inheritance  of  code  by  layering  buttons  on  top  of  one  another  and  passing  discrete 
commands  from  one  layer  to  another.  This  is  a  very  significant  attribute  in  that  it  greatly 
facilitates  compactness  and  reusability  of  code.  Specifically,  the  invisible  button  was 
essential  for  the  development  of  the  SEALAR  program  because  it  is  by  employing  this 
feature  that  the  user  is  able  to  define  a  pathway  to  a  desired  subsystem,  component  and 
piece  or  part  All  that  is  required  for  the  user  is  to  click  on  a  graphic  representation  and  the 
program  will  respond  by  displaying  a  blowup  of  the  selected  graphic. 

The  two  categories  of  layers  found  in  HyperCard  are  background  and  card. 
Everything  assigned  to  a  background  is  active  and  visible  on  every  card  of  that  same 
background  in  the  stack,  that  is  anything  placed  into  a  background  design  gets  copied  onto 
every  other  card  with  the  same  background;  this  includes  graphics,  text,  and  buttons.  The 
programmer  can  choose  to  place  graphics,  text,  or  buttons  onto  a  specific  card  and  have 
them  visible  only  when  that  particular  card  is  the  top  card  in  the  stack,  by  placing  those 
objects  into  the  card  domain.  All  objects  in  the  card  domain  are  in  the  very  top  layers  of  the 
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stack  with  background  objects  lying  below.  The  card  domain  can  be  thought  of  as  a 
foreground.  Conceptually,  it  is  very  important  to  note  that  card  objects  are  visible  and 
active  only  in  their  respective  layers,  whereas  background  objects  are  visible  and  active  for 
all  cards  sharing  a  particular  background.  In  terms  of  creating  applications,  this  subtle 
difference  between  foreground  cards  and  backgrounds  becomes  an  indispensable  tool  for 
the  programmer  to  hide  certain  action  buttons  from  the  user  at  different  points  of  the 
program  by  covering  up  an  action  button  on  a  background  card  with  an  opaque  object  on  a 
foreground  card.  Background  buttons  can  be  created  only  one  at  a  time,  each  in  its  own 
layer,  however,  the  user  can  not  discern  any  difference  between  the  two  buttons  or  the  two 
layers  because  both  opaque  buttons  are  readily  visible  and  show  no  obvious  indications  of 
being  in  two  completely  different  layers.  Careful  manipulation  of  the  background  and  card 
layers  enables  the  programmer  to  develop  a  look  and  feel  which  results  in  a  user  friendly 
interface.  This  also  allows  for  the  modeling  of  complex  data  structures  that  are  analogous 
to  everyday  metaphors. 

System  protection  for  SEALAR  is  inherently  important  for  the  establishment  of 
program  and  data  integrity.  This  is  easily  supported  by  HyperCard  in  the  form  of  its  built 
in  stack  protection  mechaiusm.  Stack  protection  is  provided  by  the  system.  The  level  of 
protection  is  determined  by  the  programmer  and  is  assigned  via  the  "protect  stack"  menu 
which  allows  for  the  selection  of  virtually  any  level  of  protection  desired.  Passwords  are 
available  options  that  can  be  used  to  protect  a  particular  stack.  A  more  sophisticated  level 
of  protection  exists  by  using  the  scripting  language  HyperTalk  which  allows  the 
programmer  to  limit  the  data  which  may  be  accessed  down  to  the  data  element  level.  This 
capability  may  be  extended  to  password  protection  which  can  be  applied  to  protect  a 


26 


specific  data  element  or  specific  function.  By  employing  the  scripting  language  HyperTalk 
a  programmer  has  complete  flexibility  with  regard  to  limiting  users  to  specific  functions  and 
data  elements. 

Another  extremely  important  aspect  of  HyperCard  is  its  linking  ability.  HyperCard 
links  are  a  method  of  establishing  a  utudirectional  pathway  from  one  card  to  another.  Links 
may  be  between  cards  in  the  same  or  different  stacks  regardless  of  either  card's  relative 
stack  position.  Bi-directional  links  can  also  be  programmed  by  inserting  a  unidirectional 
button  on  each  card  such  that  each  card  has  a  pathway  to  the  other.  To  establish  links 
between  cards  in  the  same  stack  either  the  unique  card  identification  number  is  used  as  a 
destination  address  or  the  card  name  can  be  used.  Links  to  cards  in  different  stacks  ate 
exactly  the  same  with  the  addition  of  the  new  stack  name  to  the  destination  address. 
HyperCard  linking  enables  the  programmer  to  implement  true  conceptual  relational  database 
applications,  that  is,  data  never  needs  to  be  duplicated  and  there  is  no  data  redundancy. 
This  is  accomplished  by  HyperCard's  ability  to  create  links  via  unique  identification 
numbers  that  are  independent  of  data  content 

HyperTalk  is  a  general  purpose  programming  language  that  contains  an  extensive  set 
of  commands  and  functions.  It  is  also  a  special  purpose  language  that  tends  to  be  better  for 
some  programming  tasks  than  most  other  languages,  such  as  construction  of  visual 
databases  and  educational  systems.  It  is  a  very  intuitive  and  natural  language  which  tends 
to  favor  nonprogrammers  in  its  grammatical  style.  The  object-oriented  nature  of  HyperTalk 
makes  the  scripting  portion  of  the  programs  compact,  extremely  easy  to  debug  and  very 
portable  from  one  to  the  other.  The  finished  programs  tend  to  be  very  intuitive  for  the  user 
to  (^rate  and  have  a  visual  look  and  feel  that  in  other  languages  would  be  hard  to  achieve. 
This  makes  HyperTalk  a  very  labor  saving  programming  language.  One  of  the  most 
powerful  features  of  HyperTalk  are  the  external  commands  (XCMD's)  and  external 
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functions  (XFNC's)  which  allow  virtual  unlimited  extendibility.  When  HyperTalk  was 
created  two  interface  capabilities  were  installed  called  XCMD  and  XFNC.  These  two 
items  enable  HyperTalk  to  search  the  resource  foik  of  the  stack  for  a  command  or  function 
if  it  is  not  found  with  the  stack  script.  This  capability  provides  virtual  unlimited 
extendibility  to  the  HyperTalk  language.  HyperTalk  will  search  the  resource  fork  of  the 
stack  for  an  unknown  command  of  the  type  XCMD  and  likewise  will  search  for  an 
unknown  function  of  type  XFNC  for  an  unknown  function.  Therefore,  when  a 
programmer  wishes  to  extend  the  language  for  HyperTalk,  he  can  write  a  function  or 
command  in  another  language  and  move  it  into  the  resource  of  the  stack  where  he  wishes  to 
use  it.  Consequently,  extensions  to  the  HyperTalk  language  are  always  carried  with  the 
individual  stacks  that  require  them.  Selected  commands  and  functions  from  a  library  of 
XCMD's  and  XFNCs  are  easily  moved  into  and  out  of  stacks  as  desired. 

The  HyperTalk  scripting  language  is  totally  unique  among  programming  languages. 
Command  structures  are  English  like  sentences  or  phrases  such  as  "go  to  card  8613"  or 
"set  the  user  level  to  5."  HyperTalk  is  also  very  forgiving  in  syntax  and  it  allows  multiple 
variations  in  command  structure.  This  is  a  very  important  distinction  in  terms  of  ease  of 
programming,  project  implementation  and  project  modification. 

Functions  in  HyperCard  may  be  one  of  three  types;  HyperTalk  defined,  user  defrned, 
or  XFNC.  HyperTalk  functions  behave  in  the  same  fashion  as  conventiotud  programming 
language  functions.  When  a  function  is  invoked  in  HyperTalk,  the  scripts  are  searched  in  a 
hierarchical  fashion  until  a  match  is  found.  If  it  doesn't  find  a  match  then  the  resource  fork 
is  checked  to  determine  if  a  XFNC  is  available.  This  method  of  determining  function 
location  allows  the  programmer  to  redefrne  system  functions  as  well  as  defrne  entirely  new 
ones.  The  ability  to  redefine  the  environment  proved  very  valuable  as  this  program  was 
built.  While  HyperTalk  is  powerful  enough  to  handle  most  programing  requirements,  the 


28 


ability  to  write  XCMD  and  XFNC  in  other  languages  is  extremely  useful.  This  capability 
allows  discrete  external  functions  and  procedures  to  be  executed  from  within  a  HyperCard 
stack. 

There  are  two  sound  commands  available  in  HyperTalk,  play  and  beep.  Play  requires 
a  digitized  type  resource  to  be  available  in  the  stack  for  the  voice  parameter.  The  play 
command  is  ujed  to  play  digitized  sound  or  to  play  music  form  a  string  of  notes.  Beep  is 
used  to  invoke  the  system  beep.  Another  common  sound  command  which  is  an  XCMD  is 
called  'Talk."  Talk,  uses  another  program  called  MacinTalk™,  which  is  a  product  of 
Apple  Computer  Incorporated.  It  converts  text  or  phonemes  into  computer  generated 
speech.  Both  digitized  speech  and  'Talk"  were  utilized  throughout  the  SEALAR  program 
in  an  effon  to  appeal  to  the  user’s  audio  sense  arrd  to  promote  a  friendly  "look  and  feel." 

The  most  significant  criticism  of  HyperCard  is  that  its  language  HyperTalk  is  an 
inteipretive  language.  In  some  applications  this  tends  to  degrade  execution  speed.  This  is 
offset,  however,  by  HyperCard's  rapid  search  and  card  selection  rate.  Another  limitation  is 
that,  at  present,  HyperCard  can  only  display  one  card  on  a  black  aixi  white  screen  at  a  time. 
Some  of  these  limitations  have  been  remedied  by  the  creation  of  handlers  by  individual 
programmers  in  the  form  of  XFNC's  and  XCMD's  and  are  available  in  the  public  domain. 
Presumably,  future  upgrades  will  be  made  available  that  will  move  HyperCard  into  the 
realm  of  color  graphics  and  multi  dimensional  displays.  These  features  will  serve  to  make 
the  challenges  and  options  available  to  the  programmer  even  more  fascinating  and 
interesting. 
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IV.  APPLICATION  AND  IMPLEMENTATION 


As  designed  and  implemented  the  SEALAR  prototype  is  based  upcm  a  single  graphical 
stack  which  allows  the  user  to  readily  visualize  images  of  the  rocket  system,  subsystem,  or 
component.  The  HyperCard  program  provides  the  user  with  a  visible  graphic  interface, 
supplemented  with  audio  descriptions,  and  coupled  with  a  technical  textual  description 
thereby  reducing  the  technical  knowledge  required  to  become  proficient  in  using  the 
program. 

The  stack  is  constructed  using  modular  design  features.  This  aspect  is  of  critical 
importance  because  it  enables  the  software  program  to  be  dynamic  and  respond  to  frequent 
or  periodic  updates  and  revisions.  By  maintaining  this  modularity,  changes  can  be 
implemented  within  one  module  with  no  adverse  side  effects  to  other  modules  within  the 
program. 

The  SEALAR  prototype  is  entered  at  the  subsystem  level.  The  user  is  then  asked  to 
select  one  of  seven  modeled  subsystems  available  for  examination.  This  approach  is  in  no 
way  intended  to  be  all  inclusive  or  static,  rather  it  is  intended  to  represent  a  reasonable 
subsystem  break  down  of  the  X-3  rocket  modeled.  Appendix  A  depicts  the  stack 
developed  for  the  SEALAR  prototype  program.  Conceptually,  there  would  be  seven 
virtual  stacks,  with  one  representing  each  subsystem.  Within  each  subsystem's  virtual 
stack  there  would  reside  the  actual  individual  component  stacks.  Quite  literally,  each 
component  installed  on  the  modeled  rocket  would  have  its  own  stack  consisting  of  the 
myriad  of  subcomponents  that  make  up  the  functional  unit  This  serves  to  demonstrate  the 
modularity  feature  referred  to  earlier.  As  design  changes  and  modifications  are 
contemplated  or  implemented,  only  the  corresponding  stacks  need  be  updated,  not  the 
entire  program. 
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The  SEALAR  prototype  represents  a  multi-media  database.  Graphics  are  employed  to 
represent  objects  that  were  historically  represented  by  textual  descriptors  or  attributes.  In 
this  program  the  textual  information  is  used  to  enhance  and  expand  the  meaning  of  the 
object  the  user  is  currently  viewing.  Audio  is  additionally  employed  to  enhance  the 
inmitive  environment.  When  viewed  on  the  whole,  the  program  provides  a  true  multi-media 
presentation. 

The  background  buttons  which  appear  on  every  card  of  the  stack  are  an  integral  part  of 
the  look  and  feel  of  the  SEALAR  prototype.  Examples  of  these  background  buttons 
include  HELP,  LIBRARY,  SEARCH,  etc.  The  HELP  button  allows  the  user  to  quickly 
refer  to  a  system  reference  nanual  if  disoriented  while  navigating  through  any  portion  of 
the  system.  The  TEO^'.iAN  button  gives  the  user  instant  access  to  the  pertinent  section  of 
the  "X-3  Techr.Ical  Manual"[Ref.  13],  that  applies  to  the  particular  subsystem  or 
component  currently  being  viewed.  A  copy  of  this  technical  manual  is  included  as 
Appendix  C.  The  "Previous  Card"  button  located  in  the  upper  right  hand  comer  of  every 
caiU  enables  the  user  to  return  to  the  previous  card  viewed  and  in  this  manner  literally  to 
back  out  of  the  graphical  path  just  navigated.  The  rocket  button  located  in  the  upper  left 
hand  comer  of  every  card  provides  the  user  with  the  ability  to  immediately  return  to  the 
beginning  of  the  graphical  hierarchy  of  the  subsystem  stack  so  that  multiple  subsystems  or 
components  can  be  investigated  without  having  to  exit  and  reenter  the  program. 

All  graphic  buttons  are  invisible  so  that  they  can  be  positioned  over  the  various 
graphics  found  on  each  card.  Special  buttons  are  also  utilized  throughout  this  program. 
For  example,  the  COST  button  instructs  the  HyperCard  program  to  open  a  spreadsheet 
application  in  another  program.  In  the  case  of  the  SEALAR  prototype,  the  spreadsheet 
program  employed  was  Microsoft®  Excel,  version  3.0.  This  program  exhibited  the 
capabilities  to  perform  and  display  the  required  continuous  costing  computations  and  the 
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tracking  of  the  changing  interface  relationships  in  an  efficient  and  flexible  manner.  These 
features  are  demonstrated  in  the  cost  analysis  of  the  propulsion  subsystem  included  as 
Appendix  D.  It  is  in  this  manner  that  the  component  and  subsystem  costs  and  interface 
relationships  can  be  tracked,  evaluated  and  maintained. 

The  HELP  stack  is  an  integral  part  of  the  entire  program.  It  has  been  developed  to 
provide  the  user  with  an  intuitive  look  and  feel  that  will  answer  any  program  specific 
questions  that  may  arise  at  any  level  within  the  SEALAR  prototype  program.  Help  has  a 
search  function  that  eliminates  the  need  to  page  through  the  entire  stack  to  answer  a  single 
question  and  it  fully  defines  the  functionality  of  all  background  buttons.  In  addition  to  the 
functionalities  described  above,  several  scripts  were  employed  to  automate  the  development 
process.  This  capability  signiticandy  enhanced  the  development  process  and  helped  make 
the  SEALAR  prototype  a  reality. 

The  graphics  in  the  stack  were  scanned  into  a  Macintosh  n®  computer  using  a  Hewlett 
Packard  Scan  Jet®  scanner  from  reduced  sized  blue  prints.  The  scanning  program  used 
was  called  Deskscan®  version  1.0,  developed  by  Zedcor  Inc.  The  graphics  were  then 
imported  and  enhanced  in  a  program  called  Deskpaint®  version  1.05,  also  by  Zedcor. 
They  then  were  copied  and  pasted  into  Supeipaint,  a  graphics  program  developed  by 
Silicon  Beach  Software  Inc.  From  this  Supeipaint  file  each  graphic  was  brought  into  the 
HyperCard  program  and  placed  onto  an  individual  card.  These  cards  then  comprise  the 
SEALAR  prototype  stack. 

The  SEALAR  program  can  be  run  on  any  Macintosh  Plus  with  4  megabytes  RAM 
internal  and  a  20  megabyte  harddrive.  The  installed  programs  required  on  the  computer 
include  Macintalk,  HyperCard  version  2.0  and  Microsoft  Excel  version  2.1.  The  frnal  file 
sizes  for  the  program  were  as  follows;  the  HypeiCard  frle  was  433K,  and  the  Microsoft 
Excel  file  was  17K. 
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V.  ANALYSIS  AND  CONCLUSIONS 


This  study  indicates  that  it  is  indeed  possible  to  develop  a  reliable  and  accurate  system 
for  the  tracking  of  costs  and  interface  relationships  through  the  employment  of  off  the  shelf 
multimedia  technology.  This  approach  offers  several  advantages  over  those  conventionally 
employed.  Development  time  using  this  type  of  technology  is  dramatically  reduced  due 
primarily  to  its  object-oriented  nature,  overall  system  environment,  and  extensive  set  of 
development  tools  available.  The  testing  of  the  working  prototype  can  be  carried  out 
throughout  the  development  pro.ess  to  verify  accuracy  and  program  operation.  Software 
and  hardware  acquisition  and  maintenance  are  both  relatively  inexpensive  and  easily 
attainable  because  of  the  use  of  off-the-shelf  equipment  and  programs  available 
commercially.  The  level  of  friendliness  of  the  program  greatly  facilitates  the  acceptance  by 
initial  users,  and  the  lack  of  a  formal  or  complex  query  language  significantly  reduces 
training  time.  Lastly,  because  of  the  modular  construction  of  the  program,  changes  and 
revisions  to  individual  elements  are  easily  made  and  do  not  affect  other  modules  within  the 
program. 

Having  the  basic  computer  program  completed,  it  will  now  be  relatively  simple  for  the 
continuation  of  development  into  the  next  rocket  to  be  constructed.  The  most  critical  aspect 
of  this  development  will  be  the  acquisition  of  accurate  and  detailed  costing  and  parts  data 
from  the  contractors  involved.  Additionally,  the  development  of  a  method  to  accurately 
track  manhours  for  construction,  design  and  development  and  those  costs  associated  with 
these  areas  will  be  required.  The  tracking  and  optimization  of  cost  and  interface 
interactions  will  be  critical  to  the  SEALAR  program’s  success.  In  conclusion,  it  has 
become  evident  that  this  can  be  accomplished  both  accurately  and  economically  through  the 
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employment  of  multi-media  technology.  This  approach  will  contribute  significantly  to 
SEALAR’s  viability  among  the  launch  vehicles  both  in  the  inventory  today  as  well  as  those 
on  the  drawing  boards  for  tomorrow. 

As  of  the  date  of  completion  of  this  document,  the  SEALAR  program  remains  in  the 
proof  of  concept  phase.  Initial  plans  for  a  July  1991  launch  of  the  proof  of  concept 
vehicle,  the  X-3  had  to  be  scrubbed  after  an  oxygen  leak  developed  in  the  pressurized 
oxygen  tank  during  a  static  test.  Subsequently  it  was  determined  that  all  of  the  X-3's  tanks 
needed  to  be  replaced.  Plans  now  include  the  building  of  the  X-3D,  the  follow-on  rocket, 
and  in  its  consturuction  employ  stainless  steel  tanks  vice  the  maraging  steel  of  those  used  in 
the  X-3. 
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APPENDIX  B 


DEVELOPERS  SCRIPTS 

Script  of  Stack:  "Argos  3:Desktop  Folder JFM:X3  Project" 


ooooooooooooooooooooooooooooooooooooooooooooooooodoooooecooooooooooooooooooooooooooooooooooooeoo 

oooooooooooooooooooooooooooooooooooooooooooooooo 

Script  of  Stack:  X3  Project 

This  script  controls  the  overall  operation  of  the  SEALAR  HyperCard 
program  and  stack 

ooooooooooooooooeooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooeoooooeoooooooooo 

ooepooooeooooooooooooooooooooooooooooooooooooooo 


on  opens  tack 
global  mode 
set  userlevel  to  5 
end  openStack 

on  closestack 

-  this  handler  will  automatically  compact  stack 
if  the  fireesize  of  this  stack  >  0.15  *  the  size  of  this  stack  then 
doMenu  "Compact  Stack" 
end  if 

end  closestack 
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on  gohome 
play  "BYE" 
end  gohome 


There  are  2  Backgrounds  in  Stack:  "X3  Project". 

Script  of  Background  "GRAPHIC" 

oooopoooooooeooooooooooooooooooooooooooooooooooooeoooooooooooooooeoooooooooooooooooooooooooooooo 

oooooooooooooooooooooooooooooooooooooooooooooooo 


Script  of  background:  id  8104  Graphic 

This  script  resets  the  stack  upon  termination  of  the  program,  controls 
the  synthetic  voice  simulation  and  controls  the  digitized  voice  segments 
employed  chiring  program  operation. 


oooocpoooooooooooooooooooooooooooooooooooooooooooooooooooooooeooooooooooeooeooooooooooooooooooooo 

oooooeoooeoeoooooooooooooooooooooooooooooooooooo 


on  closecard 

-  this  handler  will  automatically  reset  cards  to  original  state 

-  if  field  ’Techman"  is  visible 

if  visible  of  field  ’Techman"  =  true  then 
set  lockscreen  to  true 
hide  field  ’Techman" 
repeat  with  i=l  to  the  number  of  buttons 
show  button  i 
end  repeat 

show  background  button  ’’sorry" 
set  lockscreen  to  false 
hidemsg 

end  if 

end  closecard 
onSEALARTALKx 

-•  this  handler  will  speak  in  computer  voice  tlw  text  contained  in 

”  X.  This  procedure  requires  several  TALK  XCMD’s  and  MacinTalk 

-  must  be  in  the  system  folder. 

if  hilite  of  background  button  "VOICE"  =  true  then 
TALKx,  160, 115 

end  if 

endSEALARTALK 


on  opencard 

"  tUs  handler  will  speak  in  computer  voice  the  text  conatined  in 

-  X.  This  procedure  requires  several  TALK  XCMD’s  and  MacinTalk 

-  must  be  in  the  system  folder.  This  procedure  will  be  invoked 
“  only  if  the  individual  card  does  not  have  an  OpenCard  Handler. 

-if  hditc  of  background  button  "VOICE"  =  true  then 

-TALK  FIELD  ’Techman",  160, 115 
-end  if 
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show  card  picture 
end  q>encaid 

onretumkey 

-  this  is  a  redefinition  of  the  returnkey  function 

-  for  the  purposes  of  automating  the  find  string  command 

-  so  the  user  may  simply  hit  return  in  order  to  find  the  next 

-  occurence  of  a  find  string  in  both  the  techman  field  or 

-  the  nomenclature  field.  HyperCard  doesn't  support  this  without 
~  a  custom  handler. 

if  (char  1  to  1 1  of  msg)  =  "find  string"  then 
put  the  id  of  this  card  into  tempid 
if  visible  of  field  'Techman"  then 
set  lockscreen  to  true 
send  retiunKey  to  HyperCard 
if  tempid  o  id  of  this  card  then 
go  recent  card 
hide  card  picture 

set  visible  of  field  'Techman"  to  true 
repeat  with  i=l  to  the  number  of  buttons 
hide  button  i 
end  repeat 
end  if 

set  lockscreen  to  false 
else 

send  retumKey  to  HyperCard 
end  if 
else 

send  retumKey  to  HyperCard 
end  if 

end  retumKey 


Script  of  Background  "SEALAR  BACKGROUND  I" 


OOOOOOOOOOOOOOOOOOOOOOOOOOOOOeOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOQOOOOOOOO 


Script  of  background;  SEALAR  BACKGROUND  I 

This  script  defines  the  paramaters  and  voice  qualities  of  the  synthetic 

voice  employed  throughout  the  program 
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onSEALARTALKx 

"  this  handler  will  speak  in  computer  voice  tl^  text  contained  in 

-  X.  This  procedure  requires  several  TALK  XCMD’s  and  MacinTalk 

-  must  be  in  the  system  folder. 

TALK  X,  160, 115 

endSEALARTALK 
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There  are  15  Cards  in  Stack:  "ESCAP". 
Script  of  Card  "SEALAR  LOGO" 


O^^^^OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOCOOOOOPOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 

OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 

Script  of  Card;  SEALAR  LOGO,  id  2093 

The  script  opens  the  SEALAR  LOGO  card,  welcomes  the  user  to  the  SEALAR 
program  and  then  utilizes  the  visual  effect  iris  close  to  close  the  canL 

oooooooooooooooooooooooooooooooooooooooooooooo 


onqjenCard 

SEALARTALK  "Welcome  to  see  lar,  offering  cost  efecteve  access  to  space" 
visual  effect  iris  close 
go  next 
end  openCard 


Script  of  Card  "X3  Test  Vehicle" 


nn  nr>nn  n^ww>nfMvwloooonrlnnf^nf^r^nrta»g«<>*^^^^w^^wwHMm 

Script  of  card;  id  8720  X3  Test  Vehicle 

This  script  opens  X3  Test  Vehicle  card  and  controls  the  visual  effects 
upon  closing. 

oooooooooooooooooooooocoooooooooooooooooooooooooooooooooooooooooooooeooooooooooooooooooooooooooo 
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onqwnCard 

SEALARTALK  "X  3  test  vee  hickle" 
wait  5  seconds 
go  next 
end  openCaid 

on  closeCand 
visual  effect  iris  close 
end  closeCaid 

Script  of  Card  ''X3  Subsystems" 

ooooooooooooooooeooooDoooooooooooooooooooooooo 

Script  of  card:  id  4890  X3  Subsystems 

This  script  provides  instructions  to  program  user  to  enable  selection  of 
desired  subsystem  and  controls  visual  effects. 

OOOOOOOOOOOOOOOQOOOOOOOOOOOOOOOOOOPOOOOPOOOOOOOOOOOOOOCOOOOOOPOPOOOOOOOOOOOOOOOOOOOOOOOOOOWWOO 

oopooeoooooooooooooooooooooooooooooooooooooooo 


onopenCard 

SEALARTALK  "X  3  Sub  systum  break  down  -  please  select  the  desired,  subsystum" 
end  openCard 


on  closeCard 
visual  effect  Lis  close 
end  closeCard 
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Script  of  Card  "Engine  Cluster" 

OQOOOOOOOOOOOOOOCOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOeOOOOOOOOOOOOOOOOOeOOOOOOOOOOOOOOOOOOOOOOOOOOO 


Script  of  Card;  id  5 173  Engine  Ouster 

This  script  controls  the  synthetic  voice  simulation  and  the  visual 

effects  employed  on  the  card. 

oooooooooooooooooooooooooooooooooooeooooeoooooooooooooooooooooooooooooeooooooooooooooooeoooooooe 

oooooooooooooooooooooooooooooooooooooooooooooo 


onq)enCaid 

SEALARTALK  "Engin  cluster  Assemmbly" 
end  openCaid 

on  closeCaid 
visual  effect  iris  close 
end  closeCaid 


Script  of  Card  "Thrust  Frame" 


oooooooooooeoooooQOooooooooooooooooooooooooooooooooooooeoooocooooooooooooocooooooooooooooooooooo 


Script  of  card-  id  5853  Thrust  Frame 

This  script  controls  operation  of  synthetic  voice  and  visual  effects 
employed  on  the  card 

OOOOOPOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOQQOOOOOOOOOOOOOOOOOOOOCOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOPOOOO 
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onopenCanl 

SEALARTALK  "Thrusst  frame,  specefickadonns" 
end  openCaid 

on  closeCaid 
visual  effect  iris  close 
end  closeCaid 


Script  of  Card  "LR  101  Engine" 

OOOOCOOOOOPOOOOOOOOOOQOOOOOOOOOOOOOOOOOOOOOOOO 

Script  of  caid:  id  2791  LR  101  Engine 

This  script  controls  the  synthetic  voice  and  visual  effects  employed  on 
the  card. 

OOOOOOOOOOOOOOOOOOQOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOCOOOOOOOCOOOOOOOOOOOOOOOOOOOOOOOOOOOOOPPOOOOOO 

OOOOOOOOOOOOOOOOOOOOOOOOOPOOOOOOOOOOPOOOOOOOOO 


onopenCard 

SEALARTALK  "Rocket  dine,  L  R  1  O  1  Engin" 
end  openCaid 

on  closeCaid 
visual  effect  iris  close 
end  closeCaid 
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Script  of  Gurd  "Rocket  Center  Section" 


ooooooooooooooooooooooooooooooooooooooooooooeoooooooeoooooooooopoooooooooooooooooooooooooooooooo 


Script  of  card;  id  6376  Rocket  Center  Secdcm 

This  script  controls  the  synthetic  voice  and  visual  effects  employed  on 

the  card. 

ooooooeooeooooooeooooooooooooooooooooooooooooooooooooooeoooo0ooeoooooooeoooooooeooooeooooooooooo 

ooooooooooooooooooooooooooooooooeooooooooooooo 


on  (^nCard 

SEALARTALK  "Rocket  center  section,  specifecationns" 
end  openCard 

on  closeCard 
visual  effect  iris  close 
end  closeCard 


Script  of  Card  "Rocket  Fiwl  Tank" 


opooooooeooooooooooooooeooooooooeooooooooooooo 

Script  of  card:  id  6936  Rocket  Fuel  Tank 

This  script  controls  the  synthetic  voice  and  visual  effects  employed  on 
the  card. 
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OOOPOOOOOOOOOOOOQOOOOOOOOOOOOOOOPOCOOOOOOOOOOOOOOOOOCOOOOOOOOOOOOOOOOOOOOOOOOOOOOOQOOOOOOOOOeOOO 


oooooooooooooooooooooooooooooeoooooooooooooooo 


onopenCaid 

SEALARTALK  "Rocket  fuuU  tank,  specifecationns" 
end  openCard 

on  closeCaid 
visual  effect  iris  close 
end  closeCard 


Script  of  Card  "Rocket  Oxygen  Tank" 

OOOOOOOOOOOttOOOO^OOOOOOOOOOPOOOOOOOOOOOOOOOOOOOOOOOOOOCOOOOOOOOOOOOOOOCOOOCOOPOOOOOOOOOOOOOOOOeO 

oopooeoeoooooeooooooooooooooooooooooooooooeopo 

Script  of  card:  id  7530  Rocket  Oxygen  Tank 

This  script  controls  the  synthetic  voice  and  visual  effects  employed  on 

the  card. 

eoeeeoeooooooooopooooooooooopooooooooooooooooo 


on  openCard 

SEALARTALK  "Rocket  oxygen  tank,  specifecationns" 
end  openCard 
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on  closeCard 
visual  effect  iris  close 
end  closeCaid 


Script  of  Card  "Launch  Support  Equipment" 

OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOCOOOOOOOOOOOOOOOOPOOOOOOOO 

ooooeooooooooooooooooooooooooooooooooooooooooo 

Script  of  card:  id  8576  Launch  Support  Equipment 

This  script  controls  the  synthetic  voice  and  visual  effects  employed 

on  the  card. 


oooooooooeooooooooooooocoeoooooeoooooooooooooepopooooooooeooooooooooooooopoooooooooooooooooooooo 

oooooooooooooooooooooooooooooooooooooooooooooo 


on  openCaid 

SEALARTALK  "Launch  suppon  equipment,  design  presently  under  revision" 
end  openCard 

on  closeCaid 
visual  effect  iris  close 
end  closeCard 
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Script  of  Card  "Avionics/Payload" 

oooooooooooooooooooooooooooooooooooooooeooeooooooooooooooooooooooooooooooooooooooooooooooooooeoe 

oooooeoooooooooooooooooooooooooooooooooooeeooo 

Script  of  card:  id  7766  Avionics/Payload 

This  script  controls  the  synthetic  voice  and  visual  effects  employed 

on  the  card. 


oooooooooooooooooooooooooooooooooooooooooooooooooooooooeoooooeoooooooooooooooooooooooopooooooooo 

oooooooooooooooeoooooooooooooooooooooooooooooo 


on  openCard 

SEALARTALK  "Avey  onics,  and  payload” 
end  openCard 


on  closeCard 
visual  effect  iris  close 
end  closeCard 

Script  of  Card  "RF  Eteck  Layout" 


eoooooooooooooooooooooooeooooooooooooooooooeoo 

Script  of  card;  id  9162  RF  Deck  Layout 

This  script  controls  the  synthetic  voice  and  visual  effects  employed 

on  the  card. 
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oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 

OOOOOOCOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 


on  openCard 

SEALARTALK  "R  F  deck,  lay  out" 
end  openCard 


on  closeCard 
visual  effect  iris  close 
end  closeCaid 


Script  of  Card  'Telemetry  Deck" 

ooooeoooooooooooooooooooeoooooooeoooeoooooooooeeooooeoeoooooeoeoooooeoooooeoeoooooooooooooooeooe 


Script  of  card:  id  9986  Telemetry  Deck 

This  script  controls  the  synthetic  voice  and  visual  effects  employed  on 
the  card. 

OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOQOOOOOOOOOOPOOOOOOOOOOOOeOO^OOOOOOOOOOOOOOOOOQOO 

ooooQooooooooeoooooooooooooooooooooeoooooooooo 


on  openCard 

SEALARTALK  'Telem  cttry,  deck,  lay  out" 
end  OpenCard 

on  closeCard 
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visual  effect  iris  close 
end  closecaid 


Script  of  Card  "Battery  Deck" 

oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooeoooeoooooooooooooooooooeoooooooo 

OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 

Script  of  card:  id  10249  Battery  Deck 

This  script  controls  the  synthetic  voice  and  visual  effects  employed  on 
the  card. 

oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 

OOOOOOOOOOOOOOOdOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 


on  openCard 

SEALARTALK  "Batt  tery,  deck,  lay  out" 
end  OpenCard 

on  closeCard 
visual  effect  iris  close 
end  closeCard 


Script  of  Card  "Interface  Relationships" 

ooeooeoooooooecooooooooooooooooooooooooooooeoooooeoooooeoooooeoeeeoooooooooooooaoooooooooooooeoo 

oooooeoooooQoeoooooooooooooooooooooooooooooopo 

Script  of  card:  id  1 1402  Interface  Relationships 

This  script  controls  the  synthetic  voice  and  visual  effects  employed  on 

the  card. 
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oeoeoooooooooooooooooooeoooooooooooooooooooooooooooooooooooeooooooooooeooooooooooooooooooooooooo 


ooooeooooeoooooooooooooooooooooooeoooooeoooooo 

onopenCard 

SEALARTALK  "First  level  interface  relationship  description" 
end  openCard 

on  closeCard 
visual  effect  iris  close 
end  closeCard 
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There  are  6  Background  Fields  on  Background  "GRAPHIC". 


Script  of  Background  Field  X3  Test  Vehicle  of  Background  GRAPHIC 


on  mouseUp 

go  to  card  "X3  SUBSYSTEMS" 
end  mouseUp 


Script  of  Background  Field  BUTTONS  of  Background  GRAPHIC 

on  mouseup 
GLOBAL  CARDID 

put  CARDID  into  SECOND  ITEM  OF  line-i 
(clicklineO)  of  field  "DATA" 

SET  VISIBLE  OF  FIELD  "BUTTONS"  TO  FALSE 
show  card  picture 

REPEAT  WITH  COUNT  =  1  TO  NUMBER  OF  CARD  BUTTONS 
set  visible  of  button  COUNT  to  true 
END  REPEAT 
end  mouseup 


Script  of  Background  Field  data  of  Background  GRAPHIC 

-  EACH  LINE  NUMBER  OF  THE  FIELD  CONTAINS  TWO  DATA  ITEMS  WHICH 

-  CORRESPOND  TO  A  BUTTON  NUMBER.  IB.  LINE  1  CONTAINS  DATA  FOR 
BUTTON  12 

-  THE  FIRST  ITEM  IS  THE  CARD  ID  OF  THE  CHILD  OF  THIS  ITEM 

-  THE  SECOND  ITEM  IS  THE  CARD  ID  OF  THE  CARD  IN  THE  STACK  WHICH 
~  CORRESPONDS  TO  THIS  ITEM 


Script  of  Background  Held  Techman  of  Background  GRAPHIC 


on  mouseup 

~  this  handler  turns  show  field  "descripdon"  off  and  on 
"  show  the  card  picture  with  associated  buttons  on. 

lock  screen 
show  card  picture 

set  the  highlight  of  background  btn  "VOICE"  to  true 
set  visible  of  field  ’Techman"  to  false 
repeat  with  i=l  to  the  number  of  buttons 
show  button  i 
end  repeat 

repeat  with  i=l  to  the  number  of  cd  buttons 
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show  cd  button  i 
end  repeat 

repeat  with  i=l  to  the  number  of  cd  fields 
show  cd  fid  i 
end  repeat 
lock  screen 

end  mouseup 


There  are  0  Background  Fields  on  Background  "SEALAR  BACKGROUND  I". 
There  are  0  Card  Reids  on  Card  "SEALAR  LOGO" 

There  are  1  Card  Fields  on  Card  "X3  Test  Vehicle" 

There  are  8  Card  Fields  on  Card  "X3  Subsystems" 

Script  of  Card  Field  "card  field  id  3"  of  Card  "X3  Subsystems" 


on  mouseUp 

go  to  card  "Engine  Cluster" 
end  mruseUp 


Script  of  Card  Field  "card  field  id  4"  of  Card  "X3  Subsystems" 
on  mouseUp 

go  to  card  "ROCKET  OXYGEN  TANK" 
end  mo.iseUp 


Script  f  Card  Field  "card  field  id  5"  of  Card  "X3  Subsystems" 
on  mou  seUp 

go  to  CTTd  "ROCKET  CENTER  SECTION" 
endme  iseUp 


Script  ot  Card  Field  "card  field  id  6"  of  Card  "X3  Subsystems" 


on  mouseUp 

go  to  card  "ROCKET  FUEL  TANK" 
end  mouseUp 


Script  of  Card  Field  "card  field  id  8"  of  Card  "X3  Subsystems" 


on  mouseUp 

go  to  card  "AVIONICS/PAYLOAD" 
end  mouseUp 
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Script  of  Card  Field  "card  field  id  9"  of  Card  ‘'X3  Subsystems" 
on  mouseUp 

SEALARTALK  "RECOVERY  SUBSYSTUM  PRESENTLY  NOT  MOD  ELLED" 
go  to  card  "RECOVERY  SUBSYSTEM" 
end  mouseUp 

There  are  2  Card  Fields  on  Card  "Engine  Cluster" 

There  are  1  Card  Fields  on  Card  "Thrust  Frame" 

There  are  0  Card  Fields  on  Card  "LR  101  Engine" 

There  are  1  Card  Fields  on  Card  "Rocket  Center  Section" 

There  are  1  Card  Fields  on  Card  "Rocket  Fuel  Tank" 

There  are  1  Card  Fields  on  Card  "Rocket  Oxygen  Tank" 

There  are  1  Card  Fields  on  Card  "Launch  Support  Equipment" 

There  are  0  Card  Reids  on  Card  "Avionics/Payload" 

There  are  0  Card  Fields  on  Card  "RF  Deck  Layout" 

There  arc  0  Card  Fields  on  Card  'Telemetry  Deck" 

There  are  0  Card  Fields  on  Card  "Battery  Deck" 

There  are  0  Card  Fields  on  Card  "Interface  Relationships" 

There  are  IS  Background  Buttons  on  Background  "GRAPHIC". 

Script  of  Background  Button  'Techman"  of  Background  "GRAPHIC" 

OOOOOOOOOOOOOOOOOOCOCOCOOOOOOOOOOOOOOOOO0OOOOOOOOPOOCOOOOOOOOOCOOOOOCOOOOOOOOOOOOOOOOOOOOOOOOOOO 

OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOQOOOOOOOOOOOOOO 

Script  of  background  button:  id  4  Techman 

This  script  controls  the  transition  between  the  HyperCard  stack  and  the 
text  reference,  allowing  the  user  to  obtain  technical  information 
with  minimal  effort 
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ooooooooooooooooooooooooooooooooooooooooooooooooooooeoooooeoooooooooooeooooooooooooooooooooopooo 


oooeoooooooooooooooooooooooooooooooooooooooooo 


on  mouseUp 

-  this  handler  toggles  between  showing  field  'Techman"  and 
showing  the  card  picture  with  associated  buttons. 

PLAY  ’TECHMAN" 

if  visible  of  field  "Techman"  =  true  then 
Lock  Screen 

set  the  highlight  of  background  btn  "VOICE"  to  true 
hide  field  "Techman" 
show  card  picture 
set  scroll  of  field  "Techman"  to  1 
repeat  with  i=l  to  the  number  of  buttons 
show  button  i 
end  repeat 

repeat  with  i=l  to  the  number  of  cd  buttons 
show  cd  button  i 
end  repeat 

repeat  with  i=l  to  the  number  of  cd  fields 
show  cd  fid  i 
end  repeat 
unlock  screen 

else 

lock  screen 
hide  card  picture 
show  field  "Techman" 
set  scroll  of  field  ’Techman"  to  1 
repeat  with  i=l  to  the  number  of  buttons 
hide  button  i 
end  repeat 

repeat  with  i=l  to  the  number  of  cd  buttons 
hide  cd  button  i 
end  repeat 

repeat  with  i=l  to  the  number  of  cd  fields 
hide  cd  fid  i 
end  repeat 
Unlock  screen 


end  if 

end  mouseUp 
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Script  of  Background  Button  "Cost"  of  Background  "GRAPHIC" 


on  mouseUp 

open  "XS'Spreadsheet"  with  "Microsoft  Excel  3.0" 
end  mouseUp 


Script  of  Background  Button  "HELP"  of  Background  "GRAPHIC" 

on  mouseUp 
PLAY  "HELP" 
push  this  card 

go  to  stack  "SEALAR  HELP" 
end  mouseUp 


Script  of  Background  Button  "Previous  Card"  of  Background  "GRAPHIC" 
on  mouseUp 

-  goes  back  to  previous  view  level 
visual  effect  iris  close 
go  back 
end  mouseUp 


Script  of  Background  Button  "UP"  of  Background  "GRAPHIC" 

on  mouseUp 
-  goes  up  the  hierarchy 
-visual  effect  zoom  out 
-go  to  card  id  field  "Uplink" 
visual  effect  iris  close 
GO  TO  CD  "X3  Subsystems" 
end  mouseUp 


Script  of  Background  Button  "Find"  of  Background  "GRAPHIC" 


Script  of  button;  id  30  Find 

This  script  controls  the  operation  of  the  modified  search  fix’  the  desired 
string  through  the  field  ’Techman." 
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ooooeooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 

OOOOOOOOOOOOOOOOOOOOOPOOOOOOOOOOOOOOOOOOOOOOOO 

on  mouseUp 

—  this  hanger  provides  for  a  modified  search. 

put  the  id  of  this  card  into  tempid 

PLAY  "SEARCH" 

ask"Please  enter  Search  String." 

put  it  into  Goal 

if  visible  of  field  ’TECHMAN"  then 
set  lockscreen  to  true 

set  the  highlight  of  background  btn  "VOICE"  to  false 

put  "find  string"  &&  quote  &  Goal  &  quote  &&  "in  field  Techman"-i 

into  msg 

hide  msg 

send  retumkey  to  hypercard 
if  tempid  o  id  of  this  card  then 
go  recent 

set  the  highlight  of  background  bm  "VOICE"  to  true 
set  lockscreen  to  false 
end  if 
else 

lock  screen 
hide  card  picture 
show  field  "Techman" 
set  scroll  of  field  ’Techman"  to  1 
re^at  with  i=l  to  the  number  of  buttons 
hide  button  i 
end  repeat 

repeat  with  i=:l  to  the  number  of  cd  buttons 
hide  cd  button  i 
end  repeat 

repeat  with  i=l  to  the  number  of  cd  fields 
hide  cd  fid  i 
end  repeat 
Unlock  screen 

hide  msg 

put  "find  string"  &&  quote  &  Goal  &  quote  &&  "in  field  TECHMAN"  into  msg 
hide  msg 

send  retumkey  to  hypercard 
end  if 

end  mouseUp 
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Script  of  Background  Button  "LIBRARY"  of  Background  "GRAPHIC" 


on  mouseUp 
PLAY  "LIBRARY" 
push  card 

go  to  card  library  OF  STACK  "SEALAR" 
end  mouseUp 


Script  of  Background  Button  "EXIT"  of  Background  "GRAPHIC" 


on  mouseUp 
gohome 
go  home 
end  mouseUp 


Script  of  Background  Button  "PRINT"  of  Background  "GRAPHIC" 


on  mouseUp 
play  "PRINT" 
doMenu  Print  Card 
end  mouseUp 


Script  of  Background  Button  "GRAPHICS  REWRITE"  of  Background  "GRAPHIC" 


on  mouseup 

REPEAT  WITH  COUNT  =  1  TO  NUMBER  OF  CARD  BUTTONS 
set  the  script  of  button  COUNT  to-i 

"-  Graphic  Handler  may  be  found  in  this  cards  background"-! 

&  return  &  "On  MouseUp"  &  return  &-i 
"GRAPHIC  (number  of  me)"  &  return  &  "end  MouseUp” 
end  repeat 
end  mouseup 


Script  of  Background  Button  "VOICE"  of  Background  "GRAPHIC" 


on  mousedown 
-  toggles  voice  on/off 
if  the  hilite  of  me  then 
SEALARTALK  "VOICE  ONN" 
else 

TALK  "VOICE  OFF",  160, 115 
end  if 

end  mousedown 


Script  of  Background  Button  "INSERT  PARTNUMBER"  of  Background  "GRAPHIC" 
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on  mouseUp 

GIDBAL  BUTTONNAME 
GLOBAL  CARDID 
PUT  EMPTY  INTO  BUTTONNAME 
PUSH  CARD 

ASK  "INPUT  PARTNUMBER" 

GO  TO  STACK  COSAL 

FIND  rr  IN  FIELD  "PART  NUMBER" 

PUT  SHORT  ID  OF  THIS  CARD  INTO  CARDID 
POP  CARD 
hide  card  picture 

REPEAT  WITH  COUNT  =  1  TO  NUMBER  OF  CARD  BUTTONS 
set  visible  of  button  COUNT  to  false 
END  REPEAT 

IF  FIELD  "BUTTONS"  IS  EMPTY  THEN 
REPEAT  WITH  COUNT  =  1  TO  NUMBER  OF  CARD  BUTTONS 
PUT  ((short  name  of  CARD  BUTTON  COUNT)  &  ","  &  COUNT-. 
&  RETURN)  AFTER  FIELD  "BUTTONS" 

END  REPEAT 
END  IF 

ANSWER  "PLEASE  SELECT  BUTTON  NAME" 

SET  VISIBLE  OF  FIELD  "BUTTONS"  TO  TRUE 
end  mouseUp 


Script  of  Background  Button  "NONEJ^ONE"  of  Background  "GRAPHIC" 


on  mouseUp 

ANSWER  "ARE  YOU  SURE" 

IF  IT  o  "OK"  THEN  EXIT  MOUSEUP 
REPEAT  WITH  COUNT  =  1  TO  NUMBER  OF  CARD  BUTTONS 
PUT  "NONE,  NONE"  INTO  LINE  COUNT  OF  FIELD  "DATA" 
END  REPEAT 
end  mouseUp 


Script  of  Background  Button  "SOMETHING,NONE"  of  Background  "GRAPHIC" 


on  mouseUp 

ANSWER  "ARE  YOU  SURE" 

IF  IT  o  "OK"  THEN  EXIT  MOUSEUP 
REPEAT  WITH  COUNT  =  1  TO  NUMBER  OF  CARD  BUTTONS 
PUT  (CHAR  17  TO  25  OF  LINE  4  OF  THE  SCRIPT  OF  BUTTON  COUNT)-. 
& ",  NONE"  INTO-. 

LINE  COUNT  OF  FIELD  'DATA" 

END  REPEAT 
end  mouseUp 


Script  of  Background  Button  "Interface"  of  Background  "GRAPHIC" 
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on  mouseUp 

go  to  card  "Interface  Relationships" 
end  mouseUp 


There  are  0  Background  Buttons  on  Background  "SEALAR  BACKGROUND  I". 
There  are  0  Card  Buttons  on  Card  "SEALAR  LOGO". 


There  are  0  Card  Buttons  on  Card  "X3  Test  Vehicle". 


There  are  7  Card  Buttons  on  Card  "X3  Subsystems". 

Script  of  Card  Button  "En^ne  Section"  of  Card  "X3  Subsystems" 


on  mouseUp 

go  to  card  "Engine  Cluster" 
end  mouseUp 


Script  of  Card  Button  "Avionics/Payload"  of  Card  "X3  Subsystems" 


on  mouseUp 

go  to  card  "AVIONICS/PAYLOAD" 
end  mouseUp 

Script  of  Card  Button  "Recovery  Subsection"  of  Card  "X3  Subsystems" 


on  mouseUp 

SEALARTALK  "RECOVERY  SUBSYSTEM  PRESENTLY  NOT  MODELLED" 
go  to  card  "RECOVERY  SUBSYSTEM" 
end  mouseUp 


Script  of  Card  Button  "Fuel  Tank"  of  Card  "X3  Subsystems" 
on  mouseUp 

go  to  card  "ROCKET  FUEL  TANK" 
end  mouseUp 


Script  of  Card  Button  "Helium  Tank"  of  Card  "X3  Subsystems" 


on  mouseUp 
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go  to  card  "RCX:KET  CENTER  SECTION" 
end  mouseUp 


Script  of  Card  Button  "Oxidizer  Tank"  of  Card  ”X3  Subsystems" 


on  mouseUp 

go  to  cani  "ROCKET  OXYGEN  TANK" 
end  mouseUp 


Script  of  Card  Button  "Launch  Support "  of  Card  "X3  Subsystems" 


on  mouseUp 

go  to  card  "LAUNCH  SUPPORT  EQUIPMENT" 
end  mouseUp 


There  are  3  Card  Buttons  on  Card  "Engine  Cluster". 

Script  of  Card  Button  "Propulsion  Valve"  of  Card  "Engine  Ouster" 


—on  mouseUp 
"  goes  up  the  hierarchy 
--visual  effect  zoom  out 
-go  to  card  id  field  "Uplink" 

-end  mouseUp 
-on  mouseUp 

go  to  card  "PROPULSION  VALVE" 

—end  mouseUp 
on  mouseUp 

SEALARTALK  "PRO  PULSION  VAALLVE  PRESENTLY  NOT  MOD  ELLED" 

go  to  card  "RECOX'ERY  SUBSYSTEM" 
end  mouseUp 


Script  of  Card  Button  "Thrust  Frame"  of  Card  "Engine  Ouster" 


—on  mouseUp 
-  goes  up  the  hierarchy 
visual  effect  zoom  out 
go  to  card  id  field  "Uplink" 

—end  mouseUp 
on  mouseUp 

go  to  card  "THRUST  FRAME" 
end  mouseUp 


Script  of  Card  Button  "Engine  Assembly"  of  Card  "Engine  Cluster" 
-on  mouseUp 
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--  goes  up  the  hierarchy 
visual  effect  zoom  out 
go  to  card  id  field  "Uplink" 
—end  mouseUp 
on  mouseUp 

go  to  card  "LR  101  ENGINE" 
end  mouseUp 


There  are  0  Card  Buttons  on  Card  "Thrust  Frame". 

There  are  0  Card  Buttons  on  Card  "LR  101  Engine". 

There  are  0  Card  Buttons  on  Card  "Rocket  Center  Section". 
There  are  0  Card  Buttons  on  Card  "Rocket  Fuel  Tank". 

There  are  0  Card  Buttons  on  Card  "Rocket  Oxygen  Tank". 

There  are  0  Card  Buttons  on  Card  "Launch  Support  Equipment". 
There  are  3  Card  Buttons  on  Card  "Avionics/Payload". 

Script  of  Card  Button  "RF  Deck"  of  Card  "Avicmics/Payload" 


on  mouseUp 

go  to  card  "RF  Deck  Layout" 
end  mouseUp 


Script  of  Card  Button  "Telemetry  Deck"  of  Card  "Avionics/Payload" 


on  mouseUp 

go  to  card  'Telemetry  Deck" 
end  mouseUp 


Script  of  Card  Button  "Battery  Deck"  of  Card  "Avionics/Payload" 


on  mouseUp 
go  to  card  "Battery  Deck" 
end  mouseUp 


There  are  0  Card  Buttons  on  Card  "RF  Deck  Layout". 
There  are  0  Card  Buttons  on  Card  'Telemetry  Deck". 
There  are  0  Card  Buttons  on  Card  "Battery  Deck". 
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There  are  1  Card  Buttons  on  Card  "Interface  Reladonships". 

Script  of  Card  Button  "IL  Interface  Spreadsheet"  of  Card  "Interface  Relationships" 


on  mouseUp 

open  "IL  Interface"  with  "Microsoft  Excel  3.0" 
end  mouseUp 
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APPENDIX  C 


X3  VEHICLE  DESCRIPTION 


The  X3  rocket  vehicle  has  been  designed  primarily  to  serve  as  a  test  vehicle  to 
demonstrate  the  water  launch  and  recovery  of  reusable  pressure  fed  liquid  fueled  rockets. 
The  X3  rocket  is  a  relatively  simple  stored  gas  pressure  fed  liquid  fueled  propulsion  design 
(Huzel  and  Huang,  1971).  Pressure  fed  designs  are  generally  simpler  and  more  reliable 
than  turbopump  designs  as  the  turbopump  itself  is  generally  quite  complex.  On  the  other 
hand,  in  pressure  fed  designs,  the  fuel  and  oxidizer  tanks  must  be  stronger  to  withstand  the 
ullage  pressure.  Correspondingly  these  tanks  arc  thicker  and  heavier.  The  stronger  tanks 
provide  some  synergistic  advantages  in  simplifying  the  recovery  process  and  generally 
making  the  rocket  less  susceptible  to  handling  damage. 


X3  vehicle  specification; 

Height . 

Diameter . 

Launch  weight . 

Burnout  weight . 

Engine  thrust . 

Engine  type . 

Bum  time . 

Fuel . 

Oxidizer . 

Fuel  and  LOX  feed . 

Fuel  and  LOX  tank  material 
Guidance . 


276  in 
25  in 
30001b 
10001b 
40001b 

4  Rocketdyne  LR-101 
114  sec 
Kerosene 
Liquid  oxygen 
Helium  pressurization 
Vasco  250  maiaging  steel 
Strapdown  inertial 


Structure: 

Fuel  and  oxidizer  tank  weights  are  a  significant  issue  in  a  pressure  fed  rocket. 
Composite  materials,  cryostretched  steel  and  maraging  steel  arc  prime  candidates  for  the 
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tanks  in  terms  of  strength  to  weight  ratios  although  relatively  little  is  known  about  the 
associated  cryogenic  properties.  Composite  materials  have  provided  the  highest  strength  to 
weight  ratios  to  date  although  cryogenic  characteristics  are  virtually  unknown.  Further 
investigation  of  both  composite  materials  and  ciyostretched  steel  tankage  is  planned  in  other 
phases  of  the  SEALAR  program. 

Maraging  steel,  as  used  for  both  the  X3  vehicle  fuel  and  oxidizer  tanks,  provides  an 
excellent  strength  to  weight  ratio.  In  addition  to  containing  the  pressurized  fuel  and 
oxidizer,  the  tanks  also  serve  as  the  primary  vehicle  structure.  The  tanks  have  held  up  well 
in  a  series  of  helicopter  drop  reentry  simulation  tests.  Some  stress  corros  'on  has  been 
observed  in  test  samples. 

The  X3  rocket  fuel  is  kerosene.  The  oxidizer  is  liquid  oxygen  (LOX).  This 
combination  is  both  relatively  low  cost  and  easy  to  handle.  The  RP-1  fuel  and  LOX  tanks 
form  the  basic  rocket  structure.  Both  tanks  are  pressurized  to  600  psi  by  gaseous  helium 
supplied  from  a  titanium  pressure  vessel.  The  pressurized  RP-1  kerosene  is  also  used  as  a 
hydraulic  fluid  for  the  thrust  vector  control  CTVC)  system. 

Propulsion  subsystem: 

Helium  is  stored  in  a  high  pressure  titanium  sphere  in  a  chilled  gaseous  form  providing 
a  5-to-l  tankage  weight  saving  over  the  equivalent  ambient  temperature  storage.  The  X3 
helium  tank  contains  29.8  pounds  of  helium  at  160*  R  which  is  pressurized  to  3250  psi 
from  ground  service  prior  to  launch.  The  helium  tank  outlet  is  connected  to  a  series  of  heat 
exchangers.  A  much  higher  ullage  mass  utilization  can  be  achieved  by  preheating  the 
helium.  Additionally,  downstream  pneumatic  components  need  not  withstand  cryogenic 
temperatures.  The  heat  is  exchanged  with  the  kerosene  fuel  flowing  to  the  engines.  The 
heat  exchanger  outlet  is  connected  to  a  helium  pressure  regulator  which  regulates  the  helium 
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pressure  to  600  psi.  The  helium  regulator  used  in  the  X3  vehicle  was  originally  developed 
for  use  as  part  of  the  Agena  spacecraft  attitude  control  system.  A  relief  valve  located  on  the 
regulator  protects  the  vehicle  from  overpressure  in  case  of  a  regulator  failure.  The  regulator 
outputs  are  passed  through  pressurize/vent  valves  to  the  kerosene  and  LOX  tanks.  To 
further  minimize  the  helium  tank  size  and  weight,  the  rocket  is  initiaUy  pressurized  from  a 
ground-based  helium  supply. 

The  fuel  tank,  containing  685  pounds  (100  gallons)  of  RP-1  kerosene  jet  fuel,  is 
pressurized  to  600  psi  by  the  vehicle  helium  subsystem.  The  fuel  tank  is  manufactured  out 
of  0.060  inch  thick  Vasco  250  maraging  steel  to  provide  a  high  strength  to  weight  ratio.  A 
capacitive  sensor  within  the  tank  provides  a  measure  of  the  fuel  load  within  the  tank.  The 
LOX  tank  is  located  aft  of  the  fuel  tank  to  minimize  the  length  of  the  cryogenic  LOX 
plumbing.  The  rearward  LOX  tank  position  however  somewhat  reduces  the  vehicle 
dynamic  stability.  The  RP-1  tank  outlet  is  connected  to  the  engines  through  a  pneumatically 
operated  Emergency  Fuel  Valve  (EFV)  and  the  helium  heat  exchanger.  The  pressurized 
RP-1  is  also  used  to  operate  the  thrust  vector  control  servovalves. 

The  LOX  tank,  containing  1294  pounds  (140  gallons)  of  liquid  oxygen,  is  pressurized 
to  600  psi  by  helium  in  a  manner  similar  to  the  fuel  tank.  The  LOX  tank  is  manufactured 
from  0.060  inch  thick  Vasco  250  maraging  steel  which  provides  the  required  strength  to 
weight  ratio.  A  capacitive  sensor  within  the  tank  provides  a  measure  of  the  LOX  load 
within  the  tank.  The  LOX  tank  outlet  is  connected  to  a  Propellant  Control  Valve  (PCV). 
The  PCV  modulates  the  LOX  flow  rate  in  order  to  insure  a  simultaneous  fuel  and  LOX 
burnout.  The  PCV  position  is  controlled  from  a  signal  generated  by  the  relative  difference 
between  the  fuel  and  LOX  tank  level  sensors. 

Both  the  fuel  and  LOX  tanks  feed  a  cluster  of  four  Rocketdyne  LR-101  engines 
providing  a  total  of  4000  pounds  of  sea  level  thrust.  The  LR-101  engines  were  originally 
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used  for  vernier  steering  of  the  Atlas,  Delta  and  Thor  launch  vehicles.  In  the  X3  vehicle, 
each  engine  is  pivoted  along  one  axis.  The  cluster  of  4  gimballed  engines  provide  complete 
yaw,  pitch  and  roll  control.  The  engines  are  operated  at  a  relatively  low  chamber  pressure 
of  360  psi. 


Epeines; 

The  Rocketdyne  LR-101  engines  are  regeneratively  cooled  by  passing  the  fuel  through 
the  nozzle  and  throat  regions  prior  to  thrust  chamber  injection. 


Rocketdyne  LR-101  rocket  engine  specificatitMis  (single  chamber); 


Propellants: 


Oxidizer .  Liquid  Oxygen  (LOX) 

Fuel .  RP-1  (Kerosene) 


Thrust  chamber  physical  characteristics: 


(Combustion  chamber 


Diameter .  2.73  in 

Volume .  41.76  in^ 

Area .  5.86  in^ 

Characteristic  length .  20.00  in 

(Contraction  1/2  angle .  15  degrees 

Expansion  1/2  angle .  15  degrees 
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Nozzle: 

Throat  diameter . . 

Exit  diameter . 

Expansion  ratio . 

Throat  area  . 

Exit  area . 

Weight  (approx) . 

Steady  state  performance; 

Thrust  (sea  level) . 

Thrust  (vacuum) . 

Specific  impulse  (Isp) . 

Chamber  pressure . 

Mixture  ratio . . 

Fuel  flow  rate . 

Oxidizer  flow  rate . 

Characteristic  velocity  (C*) 

Thrust  coefficient . . 

Thrust  coefficient . 

Injector  pressure  drop . 


1.63  in 
3.87  in 
5.622  :1 
2.088  in2 
11.74  in2 

12.0  lb 


1007.5  Ibf 
1180.4  Ibf 

205.4  sec'^ 

360.0  psi 
1.9:1 

1.692  Ib/sec 
3.214  Ib/sec 
4930.  ft/sec 

1.340  (sea  level) 
1.570  (vacuum) 
275.  psid 


The  LR-101  enp^nes  are  started  by  pressurizing  the  fuel  and  LOX  tanks,  firing  an 
igniter  in  each  engine,  verifying  correct  igniter  operation  and  opening  the  EFV  and  LOX 
valves. 

The  engines  are  ignited  by  a  set  of  pyrotechnic  igniters  inserted  into  each  engine  throat 
Each  igniter  is  a  single  shot  device  using  a  solid  propellant  charge  of  hydroxyl-terminated 
polybutadiene,  ammonium  perchlorate  plus  magnesium.  The  charge  is  ignited  using  a 
standard  Atlas  electric  match  coupled  through  a  BKN03  tablet.  The  entire  charge  is 
contained  within  the  phenolic  tube.  The  flame  exits  through  opposing  vents  directly  into  the 
thrust  chamber.  The  igniter  is  held  in  the  thrust  chamber  by  an  aluminum  spider  bracket 
Correct  igniter  operation  is  verified  by  a  thermocouple  attached  to  each  igniter.  It  is 
in.perative  that  all  igniters  are  burning  prior  to  the  start  of  fuel  and  LOX  flow  or  a  hard  start 
may  result  A  hard  start  is  an  explosion  internal  to  an  engine  caused  by  an  external  flame 
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source  propagating  rearward  into  the  engine.  A  hard  start  may  result  in  a  substantial 
overpressure  which  can  permanently  damage  the  engine.  The  igniter  is  ejected 
approximately  1/2  second  after  the  engine  start  when  the  aluminum  spider  melts. 

After  engine  burnout,  the  propellant  valve  is  closed  to  retain  helium  pressure  to 
enhance  the  fuel  and  LOX  tank  strength  during  reentry.  Engine  burnout  is  identified  by 
monitoring  the  thrust  chamber  pressure.  Burnout  is  at  180  psi  corresponding  to  50%  of 
nominal  chamber  pressure.  Residual  pressure  in  the  tanks  strengthens  them  during  water 
impact.  After  landing,  the  tanks  are  vented  (made  safe)  either  by  an  RF  command  or 
manually. 

The  smaller  propulsion  system  valves  are  directly  controlled  by  electrical  solenoids. 
The  larger  valves  such  as  the  EFV  and  LOX  valves  are  operated  by  helium  pneumatic 
pressure  using  small  solenoid  pilot  valves  for  control,  fhessure  transducers  are  installed  on 
the  helium,  fuel  and  LOX  tanks.  An  additional  pressure  transducer  is  installed  on  one 
engine  to  monitor  chamber  pressure  during  flight. 

During  the  static  test  firing  phase,  additional  transducers  are  included.  Examples  of 
additional  transducers  include  fuel  and  LOX  flow  rates,  chamber  pressures  for  all  engines 
and  helium  heat  exchanger  temperatures. 

Thrust  vector  control: 

The  rocket  steering  is  controlled  by  a  Thrust  Vector  Controller  (TVC).  Each  of  the  four 
LR-101  rocket  engines  can  be  swiveled  on  one  axis  by  a  hydraulic  actuator.  The  engine 
swivel  range  is  10  degrees,  providing  a  maximum  two-engine  lateral  control  thrust  of  350 
pounds.  When  opposite  engine  pairs  are  moved  together,  yaw  or  pitch  control  are  obtained. 
Roll  control  is  obtained  by  moving  opposite  pairs  differentially.  The  command  signals  to 
the  TVC  originate  in  the  Flight  Control  (Computer  (F(X). 
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The  actuators  are  controlled  by  Moog  proportional  servo  valves.  The  pressurized  fluid 
for  the  hydraulic  actuators  is  RP-1  rocket  fuel  supplied  directly  flom  the  fuel  tank  at  S7S 
psi.  No  boost  pumps  are  used.  The  servo  valve  output  is  dumped  overboard.  The  actuator 
position  is  sensed  by  a  Linear  Voltage  Differential  Transformer  (LVDT)  and  signal 
conditioner  assembly  providing  a  voltage  proportional  to  engine  gimbal  angle.  The  LVDT 
is  rugged  and  well  protected  from  saltwater  effects. 

A  servo  controller  compares  the  FCC  commands  with  the  LVDT  sensed  actuator 
positions.  The  error  signal  is  used  to  control  the  servo  valve  so  as  to  null  the  position  error. 
The  small  signal  bandwidth  is  18  Hz  because  of  the  low  hydraulic  pressure,  the  system 
becomes  slew  rate  limited  (130/sec)  with  a  4.5  Hz  large  signal  bandwidth  (Witham,  1990). 

The  maximum  yaw  and  pitch  thrust  is  limited  to  approximately  350  pounds  by  a  10 
degree  gimbal  angle.  The  lateral  thrust  is  converted  into  a  moment  as  a  functimi  of  distance 
between  the  engines  and  the  time  varying  center  of  gravity  location.  If  the  vehicle  reaches  a 
sufficiently  high  angle  of  attack  (a)  at  a  high  dynamic  pressure  (q),  an  insufficient  control 
authority  may  allow  the  rocket  to  become  unstable.  Typically,  the  most  critical  flight  regime 
is  in  the  peak  dynamic  pressure  (max  q)  region,  near  30,000  ft.  In  this  region,  the  angle  of 
attack  is  limited  to  approximately  5  degrees.  Substantial  wind  shears  induced  by  jet  streams 
are  common  at  this  altitude.  Because  of  an  unacceptable  control  authority,  small  flns  have 
been  added  near  the  tail  to  shift  the  center  of  pressure  rearward. 

Recovery  system: 

The  X3  rocket  is  recovered  after  use  by  a  pair  of  parachutes.  At  10,000  feet,  a  drogue 
parachute  is  deployed  by  a  drogue  gun  controlled  by  the  FCC.  The  drogue  parachute  is  an 
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8  foot  diameter  Kevlar  hemi-flo  design  manufactured  by  Paranetics.  This  Kevlar  drogue 
parachute  was  initially  designed  for  a  different  version  of  the  X3  rocket  which  required  a 
very  high  altitude  drogue  parachute  deployment. 


In  this  version  of  the  X3,  the  drogue  parachute  is  used  to  provide  the  initial 
deceleration,  extract  the  main  chute  and  for  propellant  settling  in  certain  abort  situations. 


During  an  abort,  the  drogue  parachute  i  #  ^ar  of 

the  rocket  The  fuel  and  LOX  settling  ij  owing 

a  dump  through  the  engine.  In  order  t  nd  the 

LOX  is  dumped  overboard  first.  Later,  imped 

overboard. 

The  main  parachute  is  deployed  at  lute  is 

used  to  extract  the  main  chute  from  a  c  achute 

u 


is  disreefed  to  a  diameter  of  46  feet.  The  rocket  enters  the  water  tail  first  at  32  feet  per 
second.  The  fuel  and  LOX  tanks  are  pressurized  at  water  entry  to  provide  additional 
strength. 

After  landing,  a  radio  beacon,  dye  marker  and  flashing  light  assist  in  locating  the 
vehicle. 

X3  vehicle  weight  summary  (10/10/901: 

Primary  tank  structure .  344.0 

Fuel  tank 

Center  section  structure 
Helium  tank 
LOX  tank 

Instrument  bulkhead 
Oxygen  subsystem 


Pressure  vent  valve .  1 .25 

Tank  level  sensor  probe .  3.5 

Plumbing,  wiring,  misc .  3.25 
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Fuel  subsystem 

Pressure  /  vent  valve .  1.25 

Tank  level  sensor  probe .  3.0 

Plumbing,  wiring,  misc .  5.0 

Engine  section 

Engine  assembly .  75.5 

Egg  crate .  18.5 

Instrumentation .  10.0 

4  Jacket  flowmeters .  00.8 

4  Flex  lines .  2.0 

4  TVS  actuators .  7.2 

Raceway  assembly 

4  Helium  heat  exchangers .  15.0 

4  Raceway  covers .  12.0 

Wiring .  5.0 

Drag  bags 

4  Drag  bags .  12.0 

Drag  bag  packing .  20.0 

Fins .  15.0 

Center  section  assembly 

4  Prop  utilization  /  emerg  valves .  3.0 

2  PU  solenoid  valves .  2.5 

Helium  regulator .  4.0 

3/4"  check  valve .  4.0 

IXDX  pressure  /  vent  pilot  valve .  1 .25 

Fuel  pressure  /  vent  pilot  valve .  1 .25 

LOX  tank  overpressure  switch .  1.0 

Fuel  tank  overpressure  switch .  1.0 

Helium  tank  pressure  transducer .  1.0 

Fuel  tank  pressure  transducer .  0.75 

LOX  tank  pressure  transducer .  0.75 

Helium  relief  valve .  0.25 

3  Temperature  piobes .  0.25 

Plumbing,  wiring,  misc .  8.0 
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Nose  section 


Outer  skin .  26.0 

Locking  ring .  7.5 

Locking  ring  seal .  1.0 

Main  parachute .  24.5 

Drogue  parachute .  4.5 

Ehogue  chute  release  &  mortar .  12.5 

Drogue  chute  skin .  2.5 

Ring  bulkhead  and  seal .  3.0 

Honeycomb  floor .  5.0 

Recovery  beacon .  4.0 

Dye  marker .  1.0 

Plumbing,  wiring,  misc .  15.0 

Avionics  /  payload .  266.45 


Fluids 


Helium .  29.8 

Residual  fuel .  14.0 

Residual  LOX .  0.0 

Burnout  weight .  1000.0 

Useable  fuel .  685.0 

Useable  LOX .  1294.0 

Launch  weight .  2979.0 
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X3  Propubton  Equipment  Cost  Information 
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